| *** sanjayu_ has quit IRC | 00:30 | |
| *** jamesmcarthur has quit IRC | 01:22 | |
| *** jamesmcarthur has joined #zuul | 01:31 | |
| *** jamesmcarthur has quit IRC | 01:43 | |
| *** jamesmcarthur has joined #zuul | 01:44 | |
| *** jamesmcarthur has quit IRC | 02:00 | |
| *** jamesmcarthur has joined #zuul | 02:00 | |
| *** rlandy has quit IRC | 02:12 | |
| pabelanger | clarkb: yah, using pypi pre-releases today, for wheel, since that is the easiest way to get a released wheel of nodepool / zuul. Which avoids the need for asking to tag official releases every week. The idea was to also provide additional feedback before tagging a release for users | 02:38 |
|---|---|---|
| pabelanger | pypi is nice, as it just works and don't have to deal with mirror stuff | 02:38 |
| *** jamesmcarthur has quit IRC | 02:39 | |
| *** jamesmcarthur has joined #zuul | 02:40 | |
| *** jamesmcarthur has quit IRC | 02:43 | |
| *** jamesmcarthur has joined #zuul | 02:43 | |
| pabelanger | clarkb: as an example, https://github.com/ansible-network/windmill-config/blob/master/ansible/group_vars/nodepool.yaml#L36 was all that needed to change to pin to pre-release version of nodepool, and once we tag 3.6.1 / 3.7.0, we just bump that and pull again from pypi | 02:44 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: docs: add cleanup-run documentation https://review.opendev.org/662147 | 02:55 |
| *** jamesmcarthur has quit IRC | 03:45 | |
| *** jamesmcarthur has joined #zuul | 03:46 | |
| *** jamesmcarthur has quit IRC | 03:49 | |
| *** jamesmcarthur_ has joined #zuul | 03:49 | |
| clarkb | pabelanger: ya but now we create 20MB of data for pypi to store forever on every commit | 03:50 |
| clarkb | which has made pypi impossible to mirror due to other people doing similar | 03:51 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Parallelize github event processing https://review.opendev.org/662818 | 04:03 |
| SpamapS | clarkb: and worse, those kids won't get off pypi's lawn. | 05:01 |
| openstackgerrit | Merged zuul/zuul master: git: only list heads and tags references https://review.opendev.org/661185 | 05:11 |
| *** pcaruana has joined #zuul | 05:12 | |
| *** pcaruana has quit IRC | 05:23 | |
| *** pcaruana has joined #zuul | 05:28 | |
| *** raukadah is now known as chandankumar | 05:29 | |
| *** jamesmcarthur_ has quit IRC | 05:29 | |
| *** flepied has quit IRC | 05:37 | |
| *** badboy has joined #zuul | 05:38 | |
| badboy | hi guys | 05:38 |
| badboy | I think there's a bug in nodepool/zuul | 05:38 |
| badboy | for test purposes I've manually created 5 VMs with the same SSHD keys | 05:39 |
| badboy | for some reason Zuul starts a job on two VMs but only one is mentioned in the logs | 05:39 |
| badboy | after changing SSHD keys on the VMs this behaviour stopped | 05:40 |
| *** sanjayu_ has joined #zuul | 05:44 | |
| *** ianychoi has quit IRC | 06:57 | |
| *** ianychoi has joined #zuul | 06:58 | |
| *** gtema has joined #zuul | 06:58 | |
| *** flepied has joined #zuul | 07:02 | |
| *** sanjayu__ has joined #zuul | 07:10 | |
| *** sanjayu_ has quit IRC | 07:13 | |
| *** themroc has joined #zuul | 07:18 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/nodepool master: nodepool: improve static driver request handling for multi labels https://review.opendev.org/662954 | 07:25 |
| *** zbr has joined #zuul | 07:31 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 07:33 |
| *** threestrands has joined #zuul | 07:44 | |
| *** jpena|off is now known as jpena | 07:51 | |
| *** hashar has joined #zuul | 08:07 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 08:08 |
| *** flepied has quit IRC | 08:31 | |
| *** spsurya has joined #zuul | 08:51 | |
| *** lennyb has quit IRC | 08:53 | |
| *** threestrands has quit IRC | 09:14 | |
| *** themroc has quit IRC | 09:15 | |
| *** themroc has joined #zuul | 09:17 | |
| *** lennyb has joined #zuul | 09:21 | |
| openstackgerrit | Merged zuul/zuul master: test_v3: replace while loop with iterate_timeout https://review.opendev.org/662112 | 09:28 |
| *** panda is now known as panda|ruck | 09:38 | |
| *** mugsie_ is now known as mugsie | 09:52 | |
| *** flepied has joined #zuul | 10:09 | |
| *** gtema has quit IRC | 10:43 | |
| *** gtema_ has joined #zuul | 10:43 | |
| *** gtema_ is now known as gtema | 10:43 | |
| *** jpena is now known as jpena|lunch | 11:34 | |
| *** yolanda has quit IRC | 11:44 | |
| *** panda|ruck is now known as panda|ruck|eat | 11:45 | |
| *** panda|ruck|eat is now known as panda|ruck | 11:51 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Mount tmpfs on ansible tmp dir https://review.opendev.org/663015 | 12:10 |
| *** mugsie is now known as mugsie_ | 12:18 | |
| *** mugsie_ is now known as mugsie | 12:18 | |
| *** badboy has quit IRC | 12:19 | |
| *** gtema has quit IRC | 12:19 | |
| *** rlandy has joined #zuul | 12:30 | |
| *** jpena|lunch is now known as jpena | 12:32 | |
| *** pwhalen has joined #zuul | 12:33 | |
| *** panda|ruck is now known as panda|ruck|eat | 12:37 | |
| *** spsurya has quit IRC | 12:40 | |
| *** gtema has joined #zuul | 12:48 | |
| *** rlandy has quit IRC | 12:49 | |
| *** panda|ruck|eat is now known as panda|ruck | 12:51 | |
| *** jamesmcarthur has joined #zuul | 13:00 | |
| *** rlandy has joined #zuul | 13:17 | |
| *** jamesmcarthur has quit IRC | 13:20 | |
| *** jamesmcarthur has joined #zuul | 13:20 | |
| *** jamesmcarthur has quit IRC | 13:25 | |
| pabelanger | clarkb: yah, the main reason i was hoping for with pypi, is to keep the same deployment location for both released / pre-release wheels. But agree it comes with the cost of more storage on pypi. | 13:28 |
| *** rlandy_ has joined #zuul | 13:29 | |
| *** rlandy has quit IRC | 13:30 | |
| pabelanger | SpamapS: A while back you were talking about an autohold system, maybe just pausing a playbook, when user added their ssh public key to git content, am I remembering that right? | 13:32 |
| clarkb | pabelanger: ya I mean if pypi is ok with not being mirrorablr and having gigabytes of input data every day due to other projects doing similar then I dont think we should stop | 13:33 |
| clarkb | I dont know if they have an opinion though | 13:33 |
| *** rlandy_ is now known as rlandy | 13:34 | |
| clarkb | fwiw it would be nice if the mirror tooling vould be more flexible and say only mirror proper releases | 13:34 |
| clarkb | but it uses a journal so that likely gets messy | 13:34 |
| pabelanger | yah | 13:35 |
| clarkb | (you would have to intentionally skip things your local journal says you've got) | 13:35 |
| *** hashar has quit IRC | 13:42 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: [DNM] admin REST API: docker-compose PoC, frontend https://review.opendev.org/643536 | 14:17 |
| corvus | mordred, clarkb: based on http://logs.openstack.org/79/656879/1/check/zuul-jobs-test-registry/0debd7f/ara-report/result/d99f3b3a-fdcb-40fd-9040-4a4643e96d70/ i'm starting to think that buildkit has a completely different backend, even to the point that it has a different transport system when pulling layers. the system is configured to use "http://mirror.regionone.limestone.openstack.org:8082" as a | 14:19 |
| corvus | docker_mirror, but buildkit forces that to https (and fails). [note, that's not even gotten to the weird buildset mirror stuff yet, that's just a normal image build on a server configured to use our region mirror] | 14:19 |
| corvus | i suppose we can try this again once our mirrors are all ssl'd (which should be soon) | 14:20 |
| mordred | corvus: ++ | 14:20 |
| corvus | or, just to experiment, since that's a patch to zuul-jobs, it could also just pull out the docker mirror stuff temporarily | 14:21 |
| *** zbr has quit IRC | 14:21 | |
| *** zbr has joined #zuul | 14:22 | |
| clarkb | re mirrors I think next step is to replace all the regions with new mirror builds, then update new mirror builds with ssl'd docker proxies | 14:30 |
| clarkb | which won't be immediate but can probably happen fairly quickly | 14:31 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return python artifact records to Zuul https://review.opendev.org/663053 | 14:39 |
| *** sanjayu__ has quit IRC | 14:42 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return javascript content artifact records to Zuul https://review.opendev.org/663056 | 14:51 |
| *** chandankumar is now known as raukadah | 15:00 | |
| *** hashar has joined #zuul | 15:07 | |
| *** jamesmcarthur has joined #zuul | 15:11 | |
| *** themroc has quit IRC | 15:20 | |
| fungi | "ERROR: Could not find a version that satisfies the requirement python-subunit (from ara<1.0.0) (from versions: none)" http://logs.openstack.org/70/662870/2/check/zuul-build-image/a0737a7/job-output.txt.gz#_2019-06-03_23_46_16_089246 | 15:25 |
| fungi | is this a known issue? | 15:25 |
| dmsimard | fungi: no, let me check that out | 15:27 |
| dmsimard | fungi: only one hit in 48h according to logstash, could it be a fluke ? | 15:30 |
| clarkb | https://pypi.org/project/python-subunit/ it is a valid package name | 15:31 |
| dmsimard | there has been other successful runs of zuul-build-image after that failure: http://zuul.openstack.org/builds?job_name=zuul-build-image -- I would be interested in doing a recheck | 15:33 |
| *** spsurya has joined #zuul | 15:39 | |
| fungi | yep, i'll try, just didn't want to do so if there was a known problem | 15:52 |
| fungi | thanks! | 15:52 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return python artifact records to Zuul https://review.opendev.org/663053 | 16:04 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return javascript content artifact records to Zuul https://review.opendev.org/663056 | 16:04 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: DNM: test zuul-jobs artifact changes Depends-On: https://review.opendev.org/663056 https://review.opendev.org/663081 | 16:06 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: DNM: test zuul-jobs artifact changes https://review.opendev.org/663081 | 16:06 |
| *** gtema has quit IRC | 16:10 | |
| Shrews | corvus: thinking about your keeping the autohold removal at expiration... what mechanism do you think should do the deletion? e.g., should we delete expired requests on each zuul CLI autohold command? Is there a thread within the scheduler we could use to do this, or should another one be created for the cleanup? | 16:12 |
| corvus | Shrews: we iterate over all the autohold requests every time a build completes; that might be a good time to do it | 16:17 |
| corvus | Shrews: and that just made me think -- we should make sure this uses zk caching | 16:17 |
| *** jangutter has quit IRC | 16:27 | |
| corvus | tobiash: does this mean anything to you? http://logs.openstack.org/81/663081/2/check/build-javascript-content/11e6a77/ara-report/result/c24c2599-0ff7-4c69-ad97-6f4991710577/ | 16:28 |
| corvus | tobiash: it does look like that job has been failing over the past few days: http://zuul.openstack.org/builds?job_name=publish-openstack-javascript-content | 16:28 |
| clarkb | corvus: tristanC suggested we needed to rebase on top of the react-scripts update change | 16:28 |
| clarkb | corvus: and/or merge that particular change. maybe we should recheck it to see if this issue goes away with that in? | 16:29 |
| clarkb | (then prepare to monitor zuul.openstack.org ?) | 16:29 |
| corvus | clarkb: what change? | 16:29 |
| clarkb | corvus: https://review.opendev.org/#/c/659991/ | 16:30 |
| openstackgerrit | Jean-Philippe Evrard proposed zuul/zuul-jobs master: Explicitly store facts for promote https://review.opendev.org/662817 | 16:30 |
| clarkb | I think we are all afeared of merging it as is because it broke zuul.openstack.org last time we did | 16:31 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: DNM: test zuul-jobs artifact changes https://review.opendev.org/663081 | 16:31 |
| clarkb | but tristanC did more testing and wasn't able to reproduce so maybe we just pick a time to merge it when tristanC is around to help debug | 16:31 |
| corvus | okay, i added a depends-on to that | 16:31 |
| corvus | that should tell us if it will fix the javascript-content job (though it also still depends on my changes to that role, so there could be unrelated errors, but they would happen after the build) | 16:32 |
| openstackgerrit | Jean-Philippe Evrard proposed zuul/zuul-jobs master: Explicitly store date facts for promote https://review.opendev.org/662817 | 16:32 |
| *** mattw4 has joined #zuul | 16:33 | |
| corvus | also, it will be nice that at the end of this process we'll be running the javascript-content job in check/gate | 16:33 |
| *** mattw4 has quit IRC | 16:37 | |
| SpamapS | pabelanger: yes, I have a role that will do that on a change that has an SSH key added in a certain path. Still early experimental phase. | 16:44 |
| corvus | clarkb: i still see the same error: | 16:49 |
| corvus | 2019-06-04 16:46:03.884313 | ubuntu-bionic | EEXIST: file already exists, mkdir '/home/zuul/src/opendev.org/zuul/zuul/web/build' | 16:49 |
| *** hashar has quit IRC | 16:53 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Revert "Create zuul/web/static on demand" https://review.opendev.org/663099 | 16:57 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: DNM: test zuul-jobs artifact changes https://review.opendev.org/663081 | 16:57 |
| corvus | okay, moving on | 16:58 |
| *** mattw4 has joined #zuul | 16:58 | |
| corvus | pabelanger, mordred: it looks like there is some incomplete work related to the fetch-output system. here is a job in zuul-jobs which fetches python sdists from the remote host and, presumably due to an error, renames them as the *file* called "artifacts". i assume the intent was to put them in an artifact directory, but that directory doesn't exist, so it rsyncs them into a file: | 17:01 |
| corvus | http://logs.openstack.org/81/663081/3/check/build-python-release/f57892a/ara-report/ | 17:01 |
| corvus | what's the ultimate design for a job like that? | 17:01 |
| corvus | should the tarball-post playbook no longer rsync to the executor and instead just move the file on the worker node? | 17:02 |
| corvus | is it safe to assume that job always fails and no one runs it, so we can go ahead and just make that change? | 17:02 |
| corvus | or should the job continue to do the rsync itself, but just create the artifacts dir beforehand, so it doesn't rely on fetch-output? | 17:03 |
| corvus | i guess the real question is -- do we expect jobs like that in zuul jobs to conform to the fetch-output interface? are there any? how do we indicate that? | 17:03 |
| mordred | corvus: those are all great questions (and a sad bug) ... I believe the final expectation would be that tarball-post no longer rsyncs to the executor and instead just moves the file on the worker node | 17:04 |
| mordred | although I believe we were trying to get there stepwise in a fashion that if the tarball-post job continued to rsync things it would not be a problem because the final rsync targets would be teh same | 17:05 |
| corvus | okay, right now, no job in zuul-jobs uses the fetch-output role. however, we do run it in the opendev base jobs. | 17:06 |
| mordred | but the final result shoudl be the jobs, in general, shouldn't be rsyncing back to the executor but instead focus on putting thigns into the directories on the worker - because that's the most flexible - and an operator can then either have a base job that rsyncs to the executor then copies thigns to where they go, or an operator could choose to just copy directly from the worker nodes, but in both cases the | 17:06 |
| mordred | zuul-jobs job content could be used | 17:06 |
| corvus | okay, so for that to happen, then i think we need to make a big effort to move the whole zuul community in that direction | 17:07 |
| mordred | yeah | 17:07 |
| corvus | because that's basically "at some point we're going to stop rsyncing in zuul jobs/roles and leave it up to you to have fetch-output in your base jobs" | 17:08 |
| mordred | yah. in talking about it here - I'm starting to think we shoudl take the original emails on the topic and put them into a spec - so that it can be clearly documented | 17:08 |
| *** jpena is now known as jpena|off | 17:09 | |
| corvus | so we'll need to make roles compatible with not having or not-having fetch-output, then have a flag day where we say everyone using zuul-jobs either needs to have fetch-output in their base job (or have a log system which doesn't require it, though none exist atm), then we start to remove the compat rsyncs | 17:09 |
| mordred | ++ | 17:09 |
| corvus | mordred: yeah, sounds good. i bet it's not that hard really, we just need to lay out the steps, set dates, and send lots of emails. | 17:09 |
| mordred | yup | 17:09 |
| corvus | mordred: i think that means for the moment what i need to do is change the build-python-release job to mkdir artifacts on the executor, and then rm artifacts/* on the worker after rsyncing | 17:10 |
| corvus | that should be backwards and forwards compatible | 17:10 |
| corvus | (ie, we're not going to rely on our fetch-output role for the moment, and then by doing the rm, we're not going to copy twice) | 17:11 |
| mordred | you should be able to skip the rm - rsync should noop if the files are already synced, no? | 17:11 |
| corvus | good point | 17:11 |
| mordred | but - I agree in principle with the idea - make sure it doesn't yet rely on fetch-output but is also compatible with it | 17:11 |
| corvus | k, thx, i think i can proceed :) | 17:12 |
| mordred | \o/ | 17:12 |
| * mordred is going to find sandwich before infra meeting | 17:12 | |
| corvus | it looks like the revert did fix the javascript issue, so that is buggy | 17:12 |
| corvus | tobiash, clarkb, mordred, tristanC: https://review.opendev.org/663099 | 17:13 |
| corvus | i'm also now mostly afk until infra mtg | 17:13 |
| tobiash | corvus: yepp, looks like that was incomplete | 17:23 |
| clarkb | corvus: oh interseting | 17:26 |
| *** flepied has quit IRC | 17:30 | |
| *** jamesmcarthur has quit IRC | 17:46 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Revert "Revert "Create zuul/web/static on demand"" https://review.opendev.org/663108 | 17:54 |
| tobiash | corvus: I think that should work in python as well as for the js content generation job ^ | 17:54 |
| Shrews | tobiash: looking at caching for zuul autoholds, i think we are double caching data in nodepool | 17:55 |
| Shrews | tobiash: we create a TreeCache, and then use events on that tree to maintain a second cache | 17:55 |
| tobiash | Shrews: that are two distinct types of caches, the treecache caches the raw data and the second cache is the resulting object structure | 17:56 |
| tobiash | we need that to not re-parse all the json over and over agai | 17:56 |
| *** themroc has joined #zuul | 17:58 | |
| Shrews | tobiash: oh, i see now | 17:59 |
| Shrews | so, intentional double caching | 17:59 |
| tobiash | yepp :) | 17:59 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return javascript content artifact records to Zuul https://review.opendev.org/663056 | 17:59 |
| Shrews | tobiash: you probably explained that the first time around and i just forgot :) | 18:00 |
| *** themroc has quit IRC | 18:00 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return javascript content artifact records to Zuul https://review.opendev.org/663056 | 18:00 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return python artifact records to Zuul https://review.opendev.org/663053 | 18:00 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: DNM: test zuul-jobs artifact changes https://review.opendev.org/663081 | 18:01 |
| tobiash | Shrews: I don't know anymore, it's already a long time ago :) | 18:01 |
| corvus | tobiash: thanks, i added a depends-on to your revert revert to test ^ | 18:01 |
| tobiash | corvus: thanks :) | 18:01 |
| tobiash | corvus: do remember the discussion about live log routing we had a couple of weeks ago? This might become a topic for me soon. I guess this should have a spec? | 18:04 |
| corvus | tobiash: i don't entirely remember it, no. | 18:08 |
| tobiash | corvus: ok, I'll write a spec ;) | 18:08 |
| corvus | sounds like a plan :) | 18:08 |
| *** themroc has joined #zuul | 18:11 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return python artifact records to Zuul https://review.opendev.org/663053 | 18:13 |
| *** spsurya has quit IRC | 18:24 | |
| openstackgerrit | Jeremy Stanley proposed zuul/zuul-jobs master: Use password lookup for run-buildset-registry role https://review.opendev.org/663119 | 18:43 |
| corvus | tobiash: revert revert looks good! | 18:51 |
| tobiash | corvus: but it broke python this time :/ | 18:52 |
| corvus | well, at least, it looks good for the js-tarball job | 18:52 |
| corvus | yeah that | 18:52 |
| tobiash | looks like I have to fix the setup hook once more | 18:52 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Return python artifact records to Zuul https://review.opendev.org/663053 | 18:53 |
| *** ParsectiX has joined #zuul | 18:58 | |
| openstackgerrit | Merged zuul/zuul master: Revert "Create zuul/web/static on demand" https://review.opendev.org/663099 | 19:00 |
| tjgresha | has anyone seen this from nodepool? nodepool.log >> openstack.exceptions.SDKException: Server reached ACTIVE state without being allocated an IP address. - then it deletes my newly spawned VMs which do have IP assigned | 19:15 |
| ofosos | Can we so a quick show of hands? So you guys want to have a slackbot in some way or another (e.g. as an external daemon)? | 19:16 |
| ofosos | Do | 19:16 |
| fungi | tjgresha: that usually indicates a problem in your providing cloud | 19:16 |
| clarkb | fungi: tjgresha or in your clouds.yaml confg (so that nodes don't come up with a valid ip addr) | 19:18 |
| fungi | ahh, yeah if nodepool is looking for a different field in the api response and considers the addresses returned "private" or something along those lines | 19:18 |
| tjgresha | fungi: i can manually provision with the image generated by the DIB and uploaded (onto same network, same tenant, as same user, etc) | 19:20 |
| clarkb | tjgresha: does it come up with a valid "public" ip? | 19:21 |
| tjgresha | let me do a quick recheck | 19:23 |
| fungi | tjgresha: nodepool has an algorithm with which it tries to guess which addresses returned for a node is effectively public, but also provides a means to override that logic through configuration if you know how to identify the public interface | 19:25 |
| fungi | assuming this is the openstack driver, it's handled by the os-client-config library: https://docs.openstack.org/os-client-config/latest/user/network-config.html | 19:26 |
| Shrews | that's actually part of openstacksdk directly now | 19:27 |
| fungi | (so in the clouds.yaml file) | 19:27 |
| tjgresha | yes - clouds.yaml is pointed to the cloud in our lab | 19:27 |
| fungi | ahh, neat, nodepool docs still refer to the oscc docs for it | 19:27 |
| fungi | https://zuul-ci.org/docs/nodepool/configuration.html#attr-providers.[openstack].cloud | 19:27 |
| Shrews | fungi: oops, we should update that | 19:28 |
| fungi | though i suppose it's more the implicit guessing heuristics which are what you're talking about | 19:28 |
| tjgresha | yes openstack cloud =) sorry | 19:32 |
| tjgresha | fungi: so the cloud i am connected to has an internal ci-net and a public1 | 19:35 |
| fungi | if it's called "public1" and not "public" then you may have to configure that specifically in the network stanza | 19:36 |
| tjgresha | double checked.. yes i have public1 | 19:38 |
| *** hashar has joined #zuul | 19:38 | |
| *** altlogbot_1 has joined #zuul | 19:41 | |
| *** jamesmcarthur has joined #zuul | 19:42 | |
| *** jamesmcarthur has quit IRC | 19:45 | |
| *** jamesmcarthur has joined #zuul | 19:45 | |
| tjgresha | via horizon, if i include public1 at launch time it results in a error.. that is not good. i can include ci-net and then get a float from public1 tho | 19:47 |
| fungi | oh, i see, so you're using something like rfc 1918 addressing on a ci-net interface and then mapping floating ips from a public1 pool? if so, that may need to be specified in the network stanza in your clouds.yaml | 19:49 |
| tjgresha | hmm ok .. i will give that a try https://docs.openstack.org/os-client-config/latest/user/network-config.html# << -- you mean this right | 19:53 |
| SpamapS | ofosos: zuul-discuss may be a better way to gauge peoples' interest. http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss | 19:54 |
| tjgresha | fungi: just realized that was what you sent earlier =) | 19:54 |
| fungi | yup | 19:55 |
| fungi | though Shrews may have other suggestions for better reference docs as he says openstacksdk is handling that stuff directly now | 19:56 |
| tjgresha | i will catch on eventually =) | 19:56 |
| mordred | https://docs.openstack.org/openstacksdk/latest/user/config/network-config.html | 19:56 |
| mordred | the doc is pretty much the same though | 19:56 |
| fungi | we can at least update the nodepool docs to point there now | 19:57 |
| openstackgerrit | Jeremy Stanley proposed zuul/nodepool master: Update os-client-config references to openstacksdk https://review.opendev.org/663131 | 20:05 |
| fungi | Shrews: mordred: tjgresha: ^ documentation update | 20:05 |
| mordred | fungi: thnaks! | 20:05 |
| *** themroc has joined #zuul | 20:06 | |
| fungi | pumping my miserable contributor stats ;) | 20:06 |
| ofosos | SpamapS: i'll move the discussion there | 20:10 |
| *** themroc has quit IRC | 20:37 | |
| *** mattw4 has quit IRC | 20:55 | |
| *** mattw4 has joined #zuul | 20:58 | |
| *** jamesmcarthur has quit IRC | 21:00 | |
| *** jamesmcarthur has joined #zuul | 21:00 | |
| *** jamesmcarthur has quit IRC | 21:04 | |
| *** pcaruana has quit IRC | 21:07 | |
| *** hashar has quit IRC | 21:09 | |
| SpamapS | ofosos: good plan. IRC is often biased heavily toward US timezones and full-time-zuul'ers, and I want your thinking to get the full scrutiny of the community. :) | 21:09 |
| *** jamesmcarthur has joined #zuul | 21:14 | |
| clarkb | and IRCers :P | 21:17 |
| *** jamesmcarthur has quit IRC | 21:18 | |
| *** jamesmcarthur has joined #zuul | 21:20 | |
| fungi | yeah, asking on irc who likes slack... probably going to get you a set of opinions which are more biased than you would want ;) | 21:27 |
| *** jamesmcarthur has quit IRC | 21:28 | |
| *** jamesmcarthur has joined #zuul | 21:49 | |
| *** jamesmcarthur has quit IRC | 21:51 | |
| openstackgerrit | Merged zuul/nodepool master: Update os-client-config references to openstacksdk https://review.opendev.org/663131 | 21:55 |
| *** ParsectiX has quit IRC | 22:01 | |
| *** ParsectiX has joined #zuul | 22:02 | |
| *** jamesmcarthur has joined #zuul | 22:04 | |
| *** mattw4 has quit IRC | 22:08 | |
| *** ParsectiX has quit IRC | 22:11 | |
| ofosos | :) | 22:15 |
| *** jamesmcarthur has quit IRC | 22:16 | |
| *** mattw4 has joined #zuul | 22:24 | |
| *** sanjayu__ has joined #zuul | 22:52 | |
| clarkb | I'm saying hi over the cube wall to point out we just created a service announcement list for opendev services. We'll send planned outage notices and other chagne info to that list so we don't have to send them to all the various projects individually. If this sounds useful to you feel free to sign up at http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce | 22:57 |
| clarkb | It should be very low traffic | 22:59 |
| fungi | we can also send this info to the zuul-discuss ml if people would like | 23:01 |
| corvus | we could also subscribe the zuul-discuss list if we feel that's appropriate | 23:23 |
| fungi | subscribing mailing lists to mailing lists can lead to weird behaviors, though less likely i suppose when they're all on the same server | 23:31 |
| clarkb | different "vhosts" though. Not sure if that matters | 23:31 |
| fungi | if i ever get rolling again on mm3 work, it's multi-domain-capable (and i've tested that in an earlier poc with lists that only differ by domain name) | 23:33 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!