| *** saneax has quit IRC | 00:55 | |
| *** zenkuro has quit IRC | 01:24 | |
| *** saneax has joined #zuul | 04:09 | |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Remove superfluous flushes and queries from SQL reporter https://review.opendev.org/752664 | 04:29 |
|---|---|---|
| *** evrardjp has quit IRC | 04:33 | |
| *** evrardjp has joined #zuul | 04:33 | |
| *** vishalmanchanda has joined #zuul | 05:15 | |
| *** bhavikdbavishi has joined #zuul | 05:17 | |
| *** sanjayu_ has joined #zuul | 05:41 | |
| *** saneax has quit IRC | 05:44 | |
| *** bhagyashris is now known as bhagyashri|rover | 06:55 | |
| *** hashar has joined #zuul | 07:01 | |
| *** tosky has joined #zuul | 07:03 | |
| *** jcapitao has joined #zuul | 07:07 | |
| openstackgerrit | Lida Liu proposed zuul/zuul master: Add commit id to Change for mqtt reporter https://review.opendev.org/722478 | 07:20 |
| *** holser has joined #zuul | 07:34 | |
| *** bhavikdbavishi has quit IRC | 07:38 | |
| *** jpena|off is now known as jpena | 07:50 | |
| *** LLIU82 has joined #zuul | 07:54 | |
| *** avass has joined #zuul | 07:59 | |
| openstackgerrit | Simon Westphahl proposed zuul/zuul master: Optimize GitHub requests on PR merge https://review.opendev.org/752886 | 08:01 |
| *** nils has joined #zuul | 08:14 | |
| *** bhavikdbavishi has joined #zuul | 08:19 | |
| *** LLIU82 has quit IRC | 08:50 | |
| *** bhavikdbavishi1 has joined #zuul | 09:06 | |
| *** bhavikdbavishi has quit IRC | 09:08 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 09:08 | |
| openstackgerrit | Felix Edel proposed zuul/zuul master: Make reporting asynchronous https://review.opendev.org/691253 | 09:10 |
| *** avass has quit IRC | 09:39 | |
| *** sshnaidm|afk is now known as sshnaidm | 09:52 | |
| openstackgerrit | zbr proposed zuul/zuul master: Add convenience Makefile https://review.opendev.org/723837 | 10:17 |
| openstackgerrit | Alfredo Moralejo proposed zuul/zuul-jobs master: Use Train deps repo to install openvswitch https://review.opendev.org/752908 | 10:18 |
| openstackgerrit | Felix Edel proposed zuul/zuul master: Make reporting asynchronous https://review.opendev.org/691253 | 10:26 |
| openstackgerrit | zbr proposed zuul/zuul-jobs master: tox: allow tox to be upgraded https://review.opendev.org/690057 | 10:27 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add buildsets, buildset-info to subcommands https://review.opendev.org/752909 | 10:29 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add encrypt subcommand https://review.opendev.org/750709 | 10:30 |
| *** jcapitao is now known as jcapitao_lunch | 10:33 | |
| openstackgerrit | Lida Liu proposed zuul/zuul master: Add commit id to Change for mqtt reporter https://review.opendev.org/722478 | 11:04 |
| *** zenkuro has joined #zuul | 11:11 | |
| openstackgerrit | zbr proposed zuul/zuul-jobs master: bindep: perform serial install if needed https://review.opendev.org/693637 | 11:13 |
| zbr | tristanC: clarkb Can we do something about zuul-jobs-test-fetch-sphinx-tarball-with-zuul-output which was broken for more than a month? | 11:16 |
| zbr | https://zuul.opendev.org/t/zuul/builds?job_name=zuul-jobs-test-fetch-sphinx-tarball-with-zuul-output&project=zuul/zuul-jobs | 11:16 |
| zbr | I have a change that makes it nv at least to prevent blocking other patches, see https://review.opendev.org/#/c/748606/ | 11:17 |
| zbr | that test can no longer be tested after zuul was patched and we are not aware of any practical way to make it pass | 11:18 |
| *** jpena is now known as jpena|lunch | 11:30 | |
| tristanC | zbr: should it be removed if it can't be fixed? | 11:56 |
| zbr | tristanC: hard question, i am not happy to remove a test, even if broken. having it broken should remind us of fixing it. | 11:56 |
| zbr | maybe comment it? | 11:57 |
| zbr | i have an idea about how to test it using molecule and mocking zuul variables, but that is something never done on zuul-jobs, and last time i mentioned that testing tool here it did not get much.. traction. | 11:58 |
| zbr | my take is that it would be a gigantic social effort to introduce this kind of testing to zuul-jobs, even if we have very easy to use tools to run these kind of tests. | 12:00 |
| *** rfolco has joined #zuul | 12:04 | |
| *** jcapitao_lunch is now known as jcapitao | 12:09 | |
| *** rlandy has joined #zuul | 12:09 | |
| *** vishalmanchanda has quit IRC | 12:11 | |
| *** rfolco is now known as rfolco|ruck | 12:28 | |
| *** jpena|lunch is now known as jpena | 12:32 | |
| *** LLIU82 has joined #zuul | 12:43 | |
| LLIU82 | Hi, waiting for review on this one https://review.opendev.org/#/c/722478/ | 12:44 |
| *** bhavikdbavishi has quit IRC | 12:46 | |
| *** Goneri has joined #zuul | 12:50 | |
| *** avass has joined #zuul | 13:02 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Fix integration with Zuul before release https://review.opendev.org/751291 | 13:17 |
| mhu | hello zuul-maint, I'd like some advice before proceeding with zuul-client. So far I've just extracted the needed code from zuul and moved it to zuul-client. That means some code like the ZuulApp class (from zuul.cmd) gets duplicated as the ZuulClient class inherits from it | 13:21 |
| fungi | is it using distinct parts of ZuulApp which we can remove from the module in the zuul repo once the client is working? | 13:23 |
| mhu | so my approach was to move the generic bits of ZuulApp to zuul-client, and have them reimported in Zuul as a dependency. This could be avoided however by just rewriting the client from scratch | 13:23 |
| mhu | because the client is fairly independent from the other daemonized apps (in terms of logging, conf handling etc) | 13:23 |
| fungi | ahh, so it's more like just tentacles of shared framework bits | 13:24 |
| mhu | fungi, and re-import them from zuul-client, like in https://review.opendev.org/#/c/752385/ | 13:25 |
| tristanC | mhu: as commented on the review ( https://review.opendev.org/752385 ) i think this is not necessary to move the ZuulApp and that may be a source of cyclic dependencies | 13:25 |
| fungi | odds are we already have similar copies of that sort of thing in the nodepool repo, maybe even zuul-registry and son on | 13:25 |
| fungi | so on | 13:25 |
| mhu | fungi, yeah, and I realize it's probably not the best approach, talking with tristanC about it | 13:25 |
| tristanC | mhu: e.g. zuul requires the zuul-client and the zuul-client depends-on zuul | 13:25 |
| mhu | fungi, oh, then that changes things a bit | 13:25 |
| mhu | that means that code woud be worth factorizing in a single lib | 13:26 |
| fungi | well, depends on how much code there is. you could end up maintaining more code trying to put all that in a central place than having several copies | 13:26 |
| mhu | right, and again, from the zuul-client standpoint, the ZuulApp code could be done without | 13:28 |
| fungi | also i would warn against the situation in openstack where your different service components end up relying on the same client library to communicate with one another as is used to implement the user-facing command line client and sdk | 13:30 |
| fungi | you quickly wind up with tension from a conflict between the tightly-coupled needs of inter-service communication and loosely-coupled needs of users to run one client copy and interact with multiple zuul deployments (which are likely running different versions of zuul) | 13:31 |
| mhu | could we look into versioning for the Zuul REST API? There's already an info endpoint | 13:34 |
| fungi | i don't know that helps to solve the problem much | 13:37 |
| fungi | but luckily the design is such that the interface between components is zookeeper (and also gearman in the near term) | 13:39 |
| fungi | so distinct from the user-facing api anyway | 13:40 |
| fungi | i assume we want to keep it that way | 13:40 |
| mhu | the user-facing api can evolve though, for example we added the held field to build info | 13:41 |
| fungi | yes, versioning the user-facing api still makes sense for other reasons | 13:41 |
| fungi | either that or feature discovery. there are endless debates to be had about which is more effective | 13:41 |
| openstackgerrit | Alfredo Moralejo proposed zuul/zuul-jobs master: Use Train deps repo to install openvswitch https://review.opendev.org/752908 | 13:42 |
| fungi | in my mind, zuul-web and zuul-client are in a similar position as clients for user/admin-facing api communication | 13:43 |
| fungi | at least the javascript side of zuul-web | 13:43 |
| fungi | the "zuul webclient" | 13:44 |
| mhu | with the exception that the zuul webclient is usually deployed by the folks who maintain their zuul deployments, so they can ensure that versions match | 13:45 |
| mhu | the CLI would be more "in the wild" and would require a way to check for API version | 13:46 |
| fungi | well, we do actually deploy many copies of the webclient as drafts for proposed changes | 13:48 |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: WIP: Switch to using zookeeper instead of gearman for jobs (keep gearman for mergers) https://review.opendev.org/744416 | 13:48 |
| fungi | so not quite as tightly coupled as it might seem at first | 13:48 |
| zbr | zuul-main: fixed docker role to use new repos: https://review.opendev.org/#/c/752630/ | 13:51 |
| tristanC | is the correct highlight zuul-main or zuul-maint ? | 14:01 |
| zbr | tristanC: typo, i often miss to type last letter... my fault. | 14:01 |
| mhu | alright, so I think I'll just decouple the ZuulApp part, let it live in zuul so that it doesn't need a dependency on zuul-client | 14:02 |
| mhu | unless someone speaks against it | 14:03 |
| openstackgerrit | zbr proposed zuul/zuul-jobs master: Disable broken fetch-sphinx-tarball test job https://review.opendev.org/752957 | 14:05 |
| zbr | tristanC: clarkb do you prefer approach ^ ? | 14:06 |
| tobiash | tristanC: it's zuul-maint ;) | 14:09 |
| tobiash | mhu: ++ for not moving ZuulApp since that is highly targeted to run long running services. Most of that is unneeded in zuul-client and moving it would just complicate zuul releasing | 14:19 |
| *** hashar has quit IRC | 14:27 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Log missing required status checks https://review.opendev.org/718114 | 14:30 |
| tobiash | clarkb, tristanC: addressed the comment ^ | 14:30 |
| tobiash | I went to set() to keep the types aligned | 14:30 |
| zbr | zuul-maint: do we still have any reason for not dropping support for ansible 2.7? I do not see any mentioned on https://review.opendev.org/#/c/727373/ | 14:39 |
| clarkb | zbr: tobiash I think normally we wait for ansible to EOL it and we announce it? | 14:40 |
| clarkb | but once that is done we've dropped 2.5 and 2.6 in that manner | 14:40 |
| clarkb | zbr: re that broken test I think we should disable the test but then not make changes to the role without doing the base-test testing dance | 14:41 |
| zbr | lets see it... https://access.redhat.com/support/policy/updates/ansible-engine -- EOL June 18, 2020 | 14:41 |
| zbr | clarkb: ok, i will keep update of that role for later, there are ~40-50 other E208 fixes to do anyway, ones that can be tested easily. | 14:43 |
| clarkb | zbr: https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html is a better link (I don't think we care about red hat support, but ansible community) | 14:43 |
| tobiash | there it's end of life as well | 14:43 |
| clarkb | yup | 14:43 |
| zbr | the logic is very simple: never more than 3 versions, as soon they released 2.10, 2.7 was out. | 14:44 |
| clarkb | 2.10 has not been released | 14:44 |
| clarkb | unless they did that since like friday | 14:44 |
| zbr | *core* | 14:44 |
| tobiash | clarkb, corvus: it looks like when dropping 2.5 we did an anouncement on the mailing list and releasenote while with 2.6 we appearently only had the release note | 14:44 |
| fungi | we also coincide removal and deprecation, so would deprecate 2.8 when we remove 2.7 | 14:45 |
| zbr | ansible-base==2.10 was released more than a month ago. | 14:45 |
| clarkb | zbr: right but not ansible which is what we are talking about | 14:45 |
| clarkb | ansible 2.10 has an rc on pypi but that is it last I checked (on friday) | 14:45 |
| tobiash | so how do we want to do it with 2.6, just the release note or an anouncement on the mailing list as well? | 14:46 |
| corvus | For Ansible version 2.10 or later, the major release is maintained for one release cycle. When the next release comes out (for example, 2.11), the older release (2.10 in this example) is no longer maintained. | 14:46 |
| fungi | following the prior removals, we would likely want to remove 2.7, deprecate 2.8, mark 2.9 current and add 2.10 support at roughly the same time | 14:46 |
| corvus | from the page clarkb linked -- that's going to be a bit different going forward | 14:46 |
| corvus | tobiash: i think just release note should be sufficient | 14:46 |
| fungi | but yeah, if they've changed their support model, we'll need to adjust | 14:46 |
| tobiash | then landing https://review.opendev.org/727373 would be enough | 14:47 |
| corvus | tobiash: why the test_command removal in that change? | 14:49 |
| tobiash | is it? looking | 14:49 |
| zbr | as we are basically using ACD version, it means we are transitioning to shorter support cycles. | 14:49 |
| tobiash | afaik test_command was forked for <=2.7 and >=2.8 | 14:49 |
| tobiash | corvus: you mean https://review.opendev.org/#/c/727373/9/tests/remote/test_remote_zuul_stream.py ? | 14:50 |
| corvus | tobiash: ok so it still exists in FunctionalZuulStreamMixIn | 14:50 |
| corvus | ? | 14:50 |
| tobiash | yes, one assert was different in pre 2.8 so the test was duplicated | 14:51 |
| tobiash | (see line 165) | 14:51 |
| clarkb | re change in ansible support system I expect we'll still want zuul to support at least 2 versions at a time so that users can transition | 14:51 |
| corvus | clarkb: ++ | 14:52 |
| corvus | tobiash: +2 | 14:52 |
| tobiash | the the first definition was <=2.7, the second 2.8 upwards so the change changes the first one to match the 2.8 upwards version | 14:52 |
| zbr | corvus: +W on https://review.opendev.org/#/c/749702/ please | 14:54 |
| tobiash | corvus: +2 with comment on 722200 (intermediate flag), shall I +2 or do we want to respin? | 14:56 |
| tobiash | ianw: ^ | 14:56 |
| *** hashar has joined #zuul | 14:57 | |
| avass | tobiash: the windows repo sync seem to be working great by the way. I think I'll get those changes ready whenever I get time off from eks work pretty soon. :) | 15:05 |
| tobiash | avass: cool :) | 15:05 |
| clarkb | corvus: tobiash: question on https://review.opendev.org/#/c/727373/ | 15:07 |
| tobiash | clarkb: maybe deprecate it with the addition of 2.10? | 15:09 |
| clarkb | that seems reasonable | 15:09 |
| tobiash | clarkb: I didn't grok your comment at https://review.opendev.org/#/c/727373/9/releasenotes/notes/ansible-2.7-4b6504e46c18cc57.yaml@4 though | 15:11 |
| tobiash | clarkb: are you referring there to the deprecation? | 15:11 |
| clarkb | tobiash: yes, just noting that if the ansible-config.conf changes to mark 2.8 deprecated we should update the release notes too | 15:12 |
| tobiash | ah ok | 15:12 |
| *** sanjayu_ has quit IRC | 15:13 | |
| openstackgerrit | Lida Liu proposed zuul/zuul master: Add commit id and owner to Change for mqtt reporter https://review.opendev.org/722478 | 15:15 |
| openstackgerrit | Lida Liu proposed zuul/zuul master: Add commit id and owner to Change for mqtt reporter https://review.opendev.org/722478 | 15:15 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Deprecate ansible 2.8 https://review.opendev.org/753007 | 15:16 |
| tobiash | clarkb, corvus: the deprecation for whenever we want to deprecate it ^ | 15:17 |
| corvus | tobiash, clarkb: lgtm so i +3d the 2.7 removal | 15:19 |
| tobiash | :) | 15:19 |
| *** LLIU82 has quit IRC | 15:52 | |
| openstackgerrit | Merged zuul/nodepool master: Load diskimage configs before building them https://review.opendev.org/747277 | 16:09 |
| *** vishalmanchanda has joined #zuul | 16:10 | |
| openstackgerrit | Merged zuul/nodepool master: Followup test improvement to use iterate_timeout https://review.opendev.org/752539 | 16:10 |
| openstackgerrit | Merged zuul/zuul master: Log missing required status checks https://review.opendev.org/718114 | 16:17 |
| *** hashar has quit IRC | 16:18 | |
| *** jcapitao has quit IRC | 16:20 | |
| openstackgerrit | Merged zuul/zuul master: Drop support for ansible 2.7 https://review.opendev.org/727373 | 16:22 |
| *** _erlon_ has joined #zuul | 16:37 | |
| fungi | clarkb: i've left a comment on 751370 for further debate, but went ahead and approved | 16:43 |
| clarkb | fungi: I want to say git is good about doing atomic operations so truncated files seem unlikely but similar corruption does seem possible | 16:44 |
| fungi | well, i was considering the (hopefully rare) circumstances where the system loses its disk or is unceremoniously shut off, but yeah atomic operations are still probably going to mitigate most of that depending on how the fs is flushing things | 16:45 |
| fungi | seemed like a low enough risk that i'm still comfortable merging the change | 16:46 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: "Defactor" CLI code from zuul project https://review.opendev.org/753093 | 16:55 |
| *** jpena is now known as jpena|off | 16:56 | |
| *** zbr is now known as zbr|pto | 17:07 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add zuul-client testing https://review.opendev.org/752039 | 17:15 |
| mhu | I'm trying to move the definition of the zuul-client-zuul-functional job from zuul/zuul-client to zuul/zuul, but zuul tells me that zuul/zuul-client is not a known project? https://review.opendev.org/#/c/752039/12/.zuul.yaml | 17:19 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 17:20 |
| corvus | mhu: that may be coming from a different tenant | 17:20 |
| mhu | corvus, I think both projects belong to the same tenant? | 17:21 |
| mhu | yep, both listed as projects of the zuul tenant: https://zuul.opendev.org/t/zuul/projects | 17:22 |
| corvus | mhu: no i mean that message may be reported by a different tenant | 17:22 |
| corvus | other than the zuul tenant, which has zuul but not zuul-client | 17:23 |
| corvus | ie, the openstack tenant | 17:23 |
| mhu | ooh, ok | 17:23 |
| mhu | how do I fix the Verified -1 if that's the reason? | 17:24 |
| corvus | mhu: and yes, the openstack tenant has zuul in it, but not zuul-client. i don't know why zuul is included there | 17:24 |
| mhu | or should I move back the job definition in the zuul-client project? | 17:24 |
| corvus | that's an option | 17:25 |
| corvus | i wonder why zuul is in the openstack tenant | 17:27 |
| mhu | maybe the remnants of an old config? | 17:28 |
| clarkb | I think to include the bits necessary to make linting happy | 17:28 |
| clarkb | butya I think we stub that out now so we may be able to remove it | 17:28 |
| clarkb | (not sure on that) | 17:28 |
| corvus | i think removing it would be ideal (since it would be good cleanup) if someone has time to look into that | 17:28 |
| mhu | Would it be possible to add a reference to the tenant whose config causes the problem? I wasn't aware zuul belonged to another tenant and I was confused | 17:31 |
| mhu | when I saw the comment on gerrit | 17:31 |
| corvus | mhu: i think that would be swell | 17:31 |
| mhu | and with a whitelisting deployment, if you're not aware of other tenants, it might be even more puzzling | 17:32 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add zuul-client testing https://review.opendev.org/752039 | 17:33 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 17:34 |
| clarkb | commit 0326363e48df255de7ce3c9b911f41f435d50182 in openstack/project-config seems to remove the dependency on zuul/zuul but not sure if it was removed from the job itself. Looking at ozj next | 17:35 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add zuul-client-zuul-functional job (non voting) https://review.opendev.org/753096 | 17:37 |
| clarkb | 9a49d142b2f75faaa4d97bcbf2f55ddd02f29f3b is the cleanup for ozj, but zuul/zuul is still in the job | 17:38 |
| clarkb | tox-py35-on-zuul is the other place we run into it. I Think that is used to third party ci github3 for zuul from the openstack tenant | 17:40 |
| clarkb | I think that maens to remove zuul/zuul from openstack's tenant we want to move ^ that job into the zuul tenant or remove it if we don't need that third party ci | 17:41 |
| clarkb | the linting job can just have it removed. I'm pushing that chagne now | 17:41 |
| clarkb | also that is a python35 job and we've just removed py35 from zuul? | 17:43 |
| clarkb | remote: https://review.opendev.org/753098 Don't add zuul/zuul as required project on linting <- for the easy thing | 17:43 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add tenant context to syntax error message https://review.opendev.org/753101 | 17:49 |
| openstackgerrit | Merged zuul/zuul master: Clean up stale git index.lock files on merger startup https://review.opendev.org/751370 | 17:49 |
| clarkb | jlk isn't here now but might be good to check with jlk on the utility of that third party ci job for github3 | 17:50 |
| clarkb | if it is still useful bumping it to py37/py38 and hosting it in the zuul tenant is a good idea | 17:50 |
| clarkb | tristanC: looking at the ovs issue, the problem is that master is not consistently deployable? | 17:54 |
| clarkb | tristanC: in this case because dependency packages are not built? | 17:54 |
| clarkb | tristanC: the way the commit message was written I originally read that as we can't install ovs beacuse something else is already training, but I guess reality is that it cannot install because the repo itself is broken? | 17:55 |
| *** hamalq has joined #zuul | 17:57 | |
| tristanC | clarkb: i agree the commit message is not clear, but the lp-bug seems to indicate master is not working presently | 18:16 |
| clarkb | tristanC: any idea why ussuri wasn't used ( that was my last comment on the chagne) | 18:18 |
| tristanC | clarkb: that's a good question, i don't know the answer | 18:19 |
| *** nils has quit IRC | 18:43 | |
| clarkb | tristanC: I've asked #tripleo and #rdo | 18:44 |
| *** hashar has joined #zuul | 19:02 | |
| *** vishalmanchanda has quit IRC | 19:11 | |
| mhu | So I think we're good re: the path to zuul-client 0.0.2. First patch is https://review.opendev.org/#/c/751291/ which fixes some errors that were uncaught by simple unit testing. | 19:16 |
| mhu | second patch is https://review.opendev.org/#/c/753093/ which does away with the attempt to refactor common code between zuul and zuul-client, since we're not going to add zuul-client as a requirement for zuul to avoid increasing complexity. | 19:17 |
| mhu | (we can live with the little code duplication involved) | 19:18 |
| mhu | These are enough once merged to tag 0.0.2 - the resulting zuul-client would have the same coverage in terms of REST API features as when it was part of the zuul repo | 19:19 |
| mhu | then changes https://review.opendev.org/#/c/752039/, https://review.opendev.org/#/c/751264/ and https://review.opendev.org/#/c/753096/ ensure functional testing for zuul-client | 19:20 |
| mhu | zuul-maint, if that shines and sparkles with you, let's get tag 0.0.2 out to fix the PyPI package | 19:21 |
| *** hashar has quit IRC | 19:55 | |
| clarkb | tristanC: by the way I updated https://review.opendev.org/#/c/752743/ to use ensure-zookeeper last week | 21:03 |
| clarkb | tristanC: I think that is ready for review now to get off of fedora-30 | 21:03 |
| *** _erlon_ has quit IRC | 21:04 | |
| tristanC | clarkb: thank you! | 21:05 |
| clarkb | tristanC: I tried using centos-8 instead of centos-7 in a followup which broke for reasons I haven't followed up on yet. /me looks at that now before forgetting | 21:07 |
| clarkb | looks like the package we install to install the repo that we get openshift for isn't available on centos-8. I'm looking around to see if anything like that does exist for centos-8 | 21:12 |
| clarkb | hrm the documentation on this all seems to assume I am a red hat customer and want to deploy a massive cluster | 21:20 |
| * clarkb looks for dev docs | 21:20 | |
| fungi | it's weird, googling around i get the impression the underlying operating system is an integral part of openshift, and for recent versions that's fedora | 21:20 |
| clarkb | fungi: yes that too | 21:20 |
| clarkb | its the fedora core os stuff | 21:21 |
| clarkb | whatever that ended up being in the end | 21:21 |
| fungi | (not actually googling, ddging, but it's common parlance i've apparently become infected by) | 21:21 |
| clarkb | like when you play playstation games on the nintendo | 21:21 |
| fungi | it's like the answer is "you don't install openshift *on* something, you just install openshift" | 21:21 |
| *** rfolco|ruck has quit IRC | 21:22 | |
| clarkb | it seems that openshift-install is the tool and it deploys on a cloud and needs lots of resources and takes lots of time :/ | 21:23 |
| clarkb | which makes me wonder if openshift 3.11 which we currently install is the last sort of all in one setup that is viable (and it only has packages for centos 7) | 21:23 |
| clarkb | I think I may defer this and let someone else that understand openshift better tackle it | 21:25 |
| tristanC | clarkb: that sounds correct, iirc openshift 4.x installs on a cloud | 21:25 |
| clarkb | it isn't really critical I just saw centos-7 as another use of an older distro release we should address | 21:25 |
| corvus | 'openstack' is one of the options it supports | 21:25 |
| clarkb | ya but I doubt it will do well in a non nested virt openstack setup | 21:26 |
| corvus | agreed | 21:26 |
| clarkb | its a bit weird to me that a thing which I expect largely runs in containers is unable to just be run as a handful of containers in a simple way. But I guess that isn't the target audience even if it may simplify testing | 21:27 |
| clarkb | we could make a kubernetes target work for example (but I assume thats chicken before the egg in this case) | 21:28 |
| corvus | clarkb, fungi, tristanC: the openshift-install command mostly templates out terraform and k8s manifest files. it seems conceivable that if we can get some rhcos nodes we might be able to configure it to do a "bare metal" installation on them or something. | 21:33 |
| fungi | rhcos~=red hat certified operating system? | 21:34 |
| corvus | coreos (rhel8 for containers) | 21:34 |
| fungi | s/certified/core/ got it | 21:34 |
| clarkb | corvus: the okd docs say you can do something like that with fedora core os | 21:38 |
| clarkb | https://docs.okd.io/latest/installing/installing_bare_metal/installing-bare-metal.html#installing-bare-metal | 21:38 |
| tristanC | corvus: that would be very convenient indeed | 21:38 |
| corvus | clarkb: ++ | 21:39 |
| corvus | https://docs.okd.io/latest/installing/installing_bare_metal/installing-bare-metal.html#installation-bare-metal-config-yaml_installing-bare-metal | 21:39 |
| clarkb | I'm assuming you can't tell a fedora installation to make itself a coreos ? (beacuse we already have f32 images) | 21:39 |
| tristanC | clarkb: corvus: the layer after terraform is ignition, which I think needs to be started early, but perhaps there is a shortcircuit too? | 21:42 |
| clarkb | tristanC: ignition is the thing that makes coreos useful aiui | 21:42 |
| clarkb | tristanC: in the example docs above I think they are rebooting or similar to reignite the os | 21:42 |
| clarkb | its like cloud init on steroids | 21:43 |
| tristanC | well, last time I tried such thing, with version 4.1, the openshift operator configuration bootstrap was failing because it couldn't find the environment it was running in | 21:43 |
| clarkb | tristanC: https://docs.okd.io/latest/installing/installing_bare_metal/installing-bare-metal.html#installation-user-infra-machines-pxe_installing-bare-metal so ya they are (re)booting into that state | 21:45 |
| clarkb | but I guess that assumes pxe which avoiding would be nice | 21:45 |
| clarkb | I think we'd be able to reboot wit hthe correct configs already on disk? not sure | 21:46 |
| *** armstrongs has joined #zuul | 21:51 | |
| *** armstrongs has quit IRC | 21:58 | |
| fungi | and yeah, ignition seems to mostly be a cloud-init alternative with tighter ties into the init system | 22:01 |
| *** tosky has quit IRC | 22:49 | |
| *** holser has quit IRC | 23:23 | |
| ianw | fungi: won't that *also* install un-profiled packages? | 23:38 |
| ianw | (re: https://review.opendev.org/#/c/693637/) | 23:38 |
| *** rlandy has quit IRC | 23:52 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!