| mordred | corvus: so what you're saying is we should merge yesterday's patch? | 00:00 |
|---|---|---|
| corvus | basically, i made a few layers that should aid different kinds of drivers depending on complexity. if you really need full control (like openstack is using now), then there's a BaseTaskMangerProvider, which is basically just the Provider class with a task manager included (but not plumbed through to anything). | 00:00 |
| clarkb | corvus: pabelanger I've rechecked https://review.opendev.org/#/c/650431/14 to hopefully get it back green. Do we want to merge and make that release tomorrow? | 00:01 |
| clarkb | (this is the ansible 2.5 removal) | 00:01 |
| clarkb | or do we want to have the deprecation policy written and merge dfirst | 00:01 |
| corvus | then there's a SimpleTaskManager* set of classes which subclass that and implements the whole Provider/Handler/Launcher interface, with the idea that you could make an Adapeter class that just implements create/delete/list and it'll handle it for you. that should make writing simple drivers easy. | 00:02 |
| corvus | i do not think it will handle the openstack case, but i think it will handle aws+google. i should look at the azure driver wip patch and see if it looks like it's a candidate. | 00:02 |
| clarkb | corvus: are the openstack corner cases not sufficienlty pushed into shade that teh simple one could work there too ? | 00:03 |
| clarkb | wondering where the distinction for simple vs not may be | 00:03 |
| corvus | clarkb: i think merge+release tomorrow is good; i don't think we need to wait on the deprecation policy patch. but i do think we should aim to write that this week. | 00:03 |
| corvus | clarkb: consider the case of creating a server (like mordred mentioned earlier). if you need to just look up the image/flavor ids and create it, that's a series of 1-3 calls. we can handle that pretty easily since we expect the lookups to be fast. but if we have to create something and wait for it (network/volume/whatever) before creating the server, that exceeds what i've accounted for in the simple | 00:05 |
| corvus | driver | 00:05 |
| clarkb | gotcha | 00:05 |
| corvus | i have a hunch we could eek out one more level of abstraction here, and have a place where someone could inherit from the simple driver and just override the server creation method. maybe the openstack driver is a candidate for that sort of thing? | 00:06 |
| clarkb | we might actually want more sophisticated deletions in openstack too. We leak volumes in vexxhost still (not as frequently as before though) | 00:07 |
| clarkb | its possible that mgiht be addressed with more explicit delete calls of various resources | 00:07 |
| clarkb | I wonder if we'll find over time that the other clouds need similar and we move towards richer drivers. Only experience will tell I expect | 00:10 |
| *** jangutter has quit IRC | 00:13 | |
| *** sgw has joined #zuul | 00:13 | |
| *** jangutter has joined #zuul | 00:13 | |
| corvus | yeah, i think we can have a progression | 00:18 |
| *** jamesmcarthur has joined #zuul | 00:26 | |
| *** mattw4 has quit IRC | 00:43 | |
| *** sgw has quit IRC | 00:53 | |
| *** jamesmcarthur has quit IRC | 01:37 | |
| *** jamesmcarthur has joined #zuul | 02:05 | |
| *** jamesmcarthur has quit IRC | 02:20 | |
| *** rfolco has quit IRC | 02:32 | |
| *** bhavikdbavishi has joined #zuul | 03:00 | |
| *** bhavikdbavishi1 has joined #zuul | 03:03 | |
| *** bhavikdbavishi has quit IRC | 03:05 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:05 | |
| *** rlandy|bbl has quit IRC | 03:44 | |
| *** sgw has joined #zuul | 05:02 | |
| *** mhu has quit IRC | 05:07 | |
| *** swest has joined #zuul | 06:00 | |
| *** raukadah is now known as chkumar|ruck | 06:05 | |
| *** pcaruana has joined #zuul | 06:18 | |
| *** chkumar|ruck is now known as chkumar|rover | 07:32 | |
| *** AJaeger has quit IRC | 07:48 | |
| *** jcapitao|afk has joined #zuul | 08:00 | |
| *** jpena|off is now known as jpena | 08:01 | |
| *** AJaeger has joined #zuul | 08:06 | |
| *** themroc has joined #zuul | 08:26 | |
| *** tosky has joined #zuul | 08:27 | |
| *** hashar has joined #zuul | 08:37 | |
| *** corvus has quit IRC | 08:40 | |
| *** mhu has joined #zuul | 08:53 | |
| *** corvus has joined #zuul | 08:59 | |
| *** jcapitao|afk is now known as jcapitao | 09:40 | |
| *** bhavikdbavishi has quit IRC | 09:42 | |
| *** saneax has joined #zuul | 09:48 | |
| *** bhavikdbavishi has joined #zuul | 10:26 | |
| *** bhavikdbavishi1 has joined #zuul | 10:29 | |
| *** bhavikdbavishi has quit IRC | 10:30 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 10:30 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: admin REST API: zuul-web integration https://review.opendev.org/643536 | 10:33 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: admin REST API: zuul-web integration https://review.opendev.org/643536 | 10:35 |
| *** swest has quit IRC | 10:59 | |
| *** swest has joined #zuul | 11:00 | |
| *** pcaruana has quit IRC | 11:03 | |
| *** pcaruana has joined #zuul | 11:06 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: admin REST API: zuul-web integration https://review.opendev.org/643536 | 11:16 |
| *** Petar_T has joined #zuul | 11:20 | |
| *** jcapitao is now known as jcapitao|afk | 11:32 | |
| *** sshnaidm|afk is now known as sshnaidm | 11:32 | |
| Petar_T | Hi all. Are different untrusted projects under the same tenant able to share jobs and playbooks between each other? | 11:43 |
| *** hashar is now known as hasharAway | 11:44 | |
| *** Petar_T has quit IRC | 11:46 | |
| *** Petar_T has joined #zuul | 11:47 | |
| *** rfolco has joined #zuul | 12:01 | |
| *** jpena is now known as jpena|lunch | 12:04 | |
| AJaeger | Petar_T: we have a global namespace for jobs per tenant, so whatever you define as job in one project is available to all other projects in the same tenant. | 12:19 |
| AJaeger | Petar_T: roles can be shared as well, playbooks are tied to jobs AFAIR | 12:19 |
| Petar_T | AJaeger: Thanks. Does this mean that when project A uses a job from project B, B's repo will be cloned as well implicitly? | 12:21 |
| AJaeger | Zuul is accessing the playbooks and will use the roles - but nothing else is taken, AFAIK your VM will not have a cloned checkout of repo B. | 12:26 |
| Petar_T | AJaeger: Good to know. Thanks again! | 12:30 |
| *** Goneri has quit IRC | 12:31 | |
| openstackgerrit | Simon Westphahl proposed zuul/zuul master: Fix data return child jobs not skipped on failure https://review.opendev.org/698712 | 12:34 |
| openstackgerrit | Simon Westphahl proposed zuul/zuul master: Fix data return child jobs not skipped on failure https://review.opendev.org/698712 | 12:34 |
| tristanC | Petar_T: the repo with jobs or roles are cloned locally to the executor, but they are not copied to the test instance | 12:37 |
| *** sshnaidm has quit IRC | 12:37 | |
| *** hasharAway is now known as hashar | 12:38 | |
| *** sshnaidm has joined #zuul | 12:38 | |
| Petar_T | tristanC: So one way to get B's repo on the test instance is to create a job in A which inherits from B, and add B as a required project there? Is there a more elegant/idiomatic way? | 12:40 |
| mordred | Petar_T: yes, that's one thing you can do. you could also add B as a required-project to the job in B's job of the job. (we do this from time to time when a job in one repo is designed to be used by other repos but always needs itself in the job) | 12:42 |
| Petar_T | Great. Thanks everyone. One more question I thought of the other day when I was looking at job inheritance. If both a parent and a child job have a run: config item in them, does one take precedence over the other? Or are they both ran? If they're both ran - which one is ran first? | 12:44 |
| tristanC | Petar_T: iirc job.run are not inherited, and if they are like pre- or post-, then parent is ran first | 12:46 |
| mordred | run is inherited - but run in children is an override | 12:51 |
| AJaeger | Petar_T: https://zuul-ci.org/docs/zuul/user/config.html#job explains this completely | 12:52 |
| tristanC | oops right, they are inherited | 12:52 |
| mordred | pre- and post- are cumulative and are run like an onion- for jobs Base->A->B - the playbooks will run Base-Pre, A-Pre, B-Pre, B-Run, B-Post, A-Post, Base-Post | 12:53 |
| *** jcapitao|afk is now known as jcapitao | 12:53 | |
| mordred | or - you know - what AJaeger said :) | 12:53 |
| *** rlandy has joined #zuul | 12:56 | |
| swest | zuul-maintainers: I have a few open bug fixes where I would need an another pair of eyes ;) https://review.opendev.org/#/c/697023/ https://review.opendev.org/#/c/697420/ (also https://review.opendev.org/#/c/698712/ but that's just a few minutes old) | 12:59 |
| *** jpena|lunch is now known as jpena | 13:15 | |
| *** sshnaidm has quit IRC | 13:18 | |
| *** sshnaidm has joined #zuul | 13:19 | |
| *** jamesmcarthur has joined #zuul | 13:20 | |
| mordred | swest: hah. that second one is fun | 13:25 |
| *** jamesmcarthur has quit IRC | 13:36 | |
| *** jamesmcarthur has joined #zuul | 13:37 | |
| mordred | (I meant 3rd) | 13:37 |
| swest | mordred: hehe, I just had to fix the code according to the comment there | 13:42 |
| mordred | :) | 13:45 |
| *** Goneri has joined #zuul | 13:45 | |
| mordred | swest, corvus: I think all three of those are solid ^^ - but I didn't +A (or, rather, I did +A and then I removed it) because I *think* we wanted to release a 3.14 that only has the 2.5 removal? | 13:45 |
| *** jamesmcarthur has quit IRC | 13:45 | |
| swest | mordred: k, thanks | 13:46 |
| mordred | or maybe it's just the 3.13 that was important and we can include other stuff with 2.14? | 13:46 |
| mordred | 3.14 | 13:46 |
| mordred | I can't type | 13:46 |
| mordred | I need more coffee | 13:46 |
| *** jamesmcarthur has joined #zuul | 13:47 | |
| *** sgw has quit IRC | 13:48 | |
| *** jangutter has quit IRC | 13:51 | |
| *** pcaruana has quit IRC | 13:57 | |
| *** sshnaidm has quit IRC | 14:04 | |
| *** jangutter has joined #zuul | 14:05 | |
| *** Petar_T has quit IRC | 14:05 | |
| *** jamesmcarthur has quit IRC | 14:35 | |
| *** jamesmcarthur has joined #zuul | 14:35 | |
| *** pcaruana has joined #zuul | 14:36 | |
| *** jamesmcarthur has quit IRC | 14:37 | |
| *** jamesmcarthur_ has joined #zuul | 14:37 | |
| *** sshnaidm has joined #zuul | 14:49 | |
| *** hashar has quit IRC | 15:01 | |
| mhu | mnaser, got a holiday season present for you :) https://review.opendev.org/#/c/643536/ | 15:05 |
| *** sgw has joined #zuul | 15:05 | |
| mhu | JWT integration is usable but pretty ugly and there is some weird behavior I'm not sure about | 15:06 |
| mhu | but I managed to enqueue, dequeue and autohold changes from this GUI | 15:06 |
| mhu | let me know if you need help with setting up an identity provider (I've used keycloak for my tests) | 15:08 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Add note to supercedent with regards to file filters https://review.opendev.org/698733 | 15:11 |
| tobiash | mhu: awesome should this work with any openid connect provider? | 15:14 |
| mordred | neat! | 15:14 |
| *** jangutter has quit IRC | 15:15 | |
| *** jamesmcarthur_ has quit IRC | 15:15 | |
| *** jamesmcarthur has joined #zuul | 15:16 | |
| mhu | tobiash, yes | 15:16 |
| mhu | it's a christmas miracle! | 15:16 |
| tobiash | cool, I hope I can try this early next year | 15:16 |
| mhu | well I haven't tested it with other providers but it should | 15:17 |
| mordred | mhu: on my todo list is trying it with the gitea openid connect provider | 15:20 |
| mordred | mhu: of course, as I'm sure you can imagine - my todo list is absurd | 15:20 |
| mordred | so - we'll see how that goes :) | 15:20 |
| mhu | mordred, sweet, I'll see what doc I can get on that, so I can help you if you'd like | 15:21 |
| *** jamesmcarthur has quit IRC | 15:22 | |
| *** jamesmcarthur has joined #zuul | 15:23 | |
| tobiash | mhu: I answered to a question on 643536 | 15:27 |
| *** jcapitao is now known as jcapitao|afk | 15:29 | |
| mhu | tobiash, thanks, didn't think of that as a possible solution | 15:31 |
| *** jamesmcarthur has quit IRC | 15:31 | |
| *** saneax has quit IRC | 15:31 | |
| *** jamesmcarthur has joined #zuul | 15:31 | |
| fungi | mordred: my holiday wish is for somewhere i can send the backlog from my todo list and magic elves will make it all happen while i drink^H^H^H^H^Hsleep | 15:32 |
| mordred | fungi: isn't that what's happening while I drink? that explains many things ... | 15:32 |
| fungi | yeah, but in that case the elves are drunk too | 15:33 |
| *** saneax has joined #zuul | 15:33 | |
| fungi | ever seen children's toys assembled by drunk elves? it's not pretty | 15:33 |
| fungi | so, sober elves. i'm wishing for sober elves this time around | 15:34 |
| *** jamesmcarthur has quit IRC | 15:34 | |
| *** jamesmcarthur has joined #zuul | 15:34 | |
| clarkb | i that where the island of misfit toys toys originate? | 15:39 |
| fungi | drunk elves? quite probably | 15:40 |
| mordred | drunk elves sound ... less than productive | 15:41 |
| *** jcapitao|afk is now known as jcapitao | 15:48 | |
| *** chkumar|rover is now known as raukadah|r | 15:49 | |
| *** raukadah|r is now known as raukadah | 15:50 | |
| *** avass has joined #zuul | 15:55 | |
| corvus | mordred: yeah, the plan was just to remove 2.5 in 3.14... but it was probably more important to keep things stable for 3.13... i doubt anyone is going to want just the removal of 2.5 without bugfixes... so i think we could merge them. what do folks think? | 16:07 |
| *** jpena is now known as jpena|off | 16:07 | |
| *** jamesmcarthur has quit IRC | 16:09 | |
| *** jamesmcarthur has joined #zuul | 16:10 | |
| mordred | corvus: I'm fine either way | 16:12 |
| *** themroc has quit IRC | 16:13 | |
| *** irclogbot_2 has quit IRC | 16:14 | |
| *** jamesmcarthur has quit IRC | 16:15 | |
| *** jamesmcarthur has joined #zuul | 16:16 | |
| mnaser | mhu: thats awesome, i think i am going to try and find time to get through it\ | 16:16 |
| *** irclogbot_3 has joined #zuul | 16:16 | |
| *** mattw4 has joined #zuul | 16:25 | |
| clarkb | corvus: related mgoddard has a question on the openstack discuss list related to stable jobs and updating ansible | 16:28 |
| clarkb | any chance you or fungi want to take that one (you had good arguments for why this was worthwhile when brought up earlier this week) | 16:29 |
| fungi | as in why it's a good idea to pin the python you want in stable branches? i can take a stab at answering after the release meeting is done | 16:30 |
| fungi | i too saw that question and flagged it for later | 16:31 |
| clarkb | no, how to handle ansible upgrades | 16:31 |
| corvus | i think mgoddard's proposed solution sounds good | 16:31 |
| clarkb | the python version change us fallout from the ansible upgrade | 16:31 |
| corvus | the concern seems particularly around the python version; so specifying that in the job sounds good | 16:31 |
| clarkb | (which maybe means pinning ansible but then we remove support eventually too) | 16:31 |
| corvus | (note the proposed solution is not to pin ansible, but to pin python) | 16:31 |
| corvus | mgoddard suggests setting ansible_python_interpreter to python2 | 16:32 |
| mgoddard | I tried doing that in zuul job vars, but it seemed to be overridden by some host vars | 16:32 |
| corvus | mgoddard: hrm, that should work; do you have a link to the failed attempt? | 16:33 |
| mgoddard | are you proposing that zuul config would include it on stable branches? | 16:33 |
| corvus | mgoddard: iiuc, that is your proposal, which i agree with | 16:33 |
| mgoddard | https://review.opendev.org/698718 | 16:33 |
| mgoddard | to rephrase, would this by done for all projects, or will projects need to add their own zuul config? | 16:34 |
| corvus | mgoddard: i think individual projects would need to do it | 16:35 |
| mgoddard | https://2636029923414340a2c8-da9bd67ce2281bb41bf3df3e007407f6.ssl.cf1.rackcdn.com/698718/1/check/kolla-ansible-ubuntu-source/d2020a8/zuul-info/inventory.yaml | 16:35 |
| mgoddard | hopefully it has not broken too many projects | 16:35 |
| corvus | yep, there's the problem... | 16:35 |
| corvus | auto was set as a hostvar | 16:35 |
| *** avass has quit IRC | 16:36 | |
| mgoddard | I don't think we're doing that | 16:37 |
| corvus | nope, i'm looking into whether that's a zuul bug | 16:37 |
| Shrews | i think we might need to create nodes with python_path set to python2? i don't think changing that is settable via zuul... though i am still traversing the changelogs | 16:39 |
| corvus | mgoddard: in the mean time, can you try setting that under host-vars instead of vars? not the syntax is a little different (you need the node name as a dict) https://zuul-ci.org/docs/zuul/user/config.html#attr-job.host-vars | 16:40 |
| corvus | Shrews: this should be user-accessible | 16:40 |
| Shrews | i would hope, but not seeing it yet | 16:40 |
| Shrews | https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/server.py#L1372-L1388 | 16:41 |
| corvus | mgoddard: i left a commento n https://review.opendev.org/698718 | 16:41 |
| mgoddard | corvus: thanks, done | 16:41 |
| tobiash | corvus: from my point of view view I'd not require a release with only 2.5 removal so I think we could merge them too | 16:42 |
| *** jamesmcarthur has quit IRC | 16:42 | |
| corvus | Shrews: right, so if ansible_python_interpreter is set as a hostvar by the user, that shouldn't have any effect (line 1388) | 16:42 |
| Shrews | corvus: oh, setdefault(), gotcha | 16:42 |
| corvus | but it does mean that it will *always* be set as a hostvar, whether by the user or by zuul. so it's not possible to use it as a regular var | 16:43 |
| *** jamesmcarthur has joined #zuul | 16:43 | |
| Shrews | my eyes decided to ignore that | 16:43 |
| corvus | i wonder if we should check to see if ansible_python_interpreter is set as a var, and if it is, skip the entire block that Shrews highlighted | 16:44 |
| clarkb | corvus that is because different nodes can have different puthons in the same nodeset I expect? | 16:44 |
| SpamapS | Yes, that's important actually. | 16:44 |
| clarkb | and then get hit by ansible var precedence | 16:44 |
| fungi | and in fact opendev has some jobs like that | 16:44 |
| fungi | (different nodes with different python interpreters) | 16:45 |
| fungi | ((in the same job)) | 16:45 |
| fungi | mixed-platform multi-node jobs really | 16:45 |
| corvus | yep. i think this is mostly working as intended, except in the case where a user sets ansible_python_interpreter as a regular var; they would expect it to apply to all hosts, but it applies to none. | 16:46 |
| corvus | i think we either need 1) a fix like i just described or 2) a doc note saying "use a host-var for ansible_python_interpreter instead" | 16:47 |
| *** jamesmcarthur_ has joined #zuul | 16:47 | |
| *** jamesmcarthur has quit IRC | 16:51 | |
| *** mhu has quit IRC | 16:56 | |
| tobiash | corvus: I'd be in favor of a doc note as this is the more natural way as things like this should at least be encouraged as hostvars, but I'd not object to do both | 17:03 |
| Shrews | i like 2 as well | 17:04 |
| *** jamesmcarthur_ has quit IRC | 17:06 | |
| corvus | what do you think about group vars? setting ansible_python_interpreter by group var is pretty common, yeah? at least the docs say so: https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html#using-python-3-on-the-managed-machines-with-commands-and-playbooks | 17:06 |
| Shrews | that sounds like a reasonable thing to support | 17:09 |
| mgoddard | corvus: host-vars does seem to have worked: http://zuul.openstack.org/stream/1e9629edf2954a439b9f681fb37631f1?logfile=console.log | 17:16 |
| *** mhu has joined #zuul | 17:17 | |
| pabelanger | yah, host-vars for ansible_python_interpreter do work. we use it in zuul.a.c | 17:17 |
| *** sshnaidm has quit IRC | 17:18 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Don't set ansible_python_interpreter if in vars https://review.opendev.org/698774 | 17:23 |
| corvus | mgoddard: \o/ | 17:23 |
| mgoddard | thanks for the help | 17:23 |
| mgoddard | still, I wonder who else this will affect | 17:24 |
| corvus | pabelanger, tobiash, mordred, ianw, Shrews: ^ 698774 implements the all-var and group-var bypass. i'm happy to adjust that to whatever approach we want to take. | 17:24 |
| *** jpena|off is now known as jpena | 17:27 | |
| *** jamesmcarthur has joined #zuul | 17:32 | |
| *** sgw has quit IRC | 17:34 | |
| fungi | mgoddard: in opendev at least, anyone it impacts will benefit from 1. actually using python3 for further development, and 2. having more explicit job definitions for things which actually need python2.7 | 17:38 |
| fungi | which does mean stable branch changes, but at least they're stable branch changes which make formerly-implicit requirements explicit | 17:39 |
| fungi | which is really something you should want in a stable branch anyway | 17:40 |
| *** bhavikdbavishi has quit IRC | 17:43 | |
| *** sgw has joined #zuul | 17:51 | |
| *** jamesmcarthur has quit IRC | 18:04 | |
| *** jamesmcarthur has joined #zuul | 18:04 | |
| *** jamesmcarthur has quit IRC | 18:07 | |
| *** jamesmcarthur has joined #zuul | 18:07 | |
| *** igordc has joined #zuul | 18:21 | |
| *** jamesmcarthur has quit IRC | 18:22 | |
| *** jpena is now known as jpena|off | 18:36 | |
| *** saneax has quit IRC | 18:37 | |
| *** jcapitao has quit IRC | 18:43 | |
| SpamapS | fungi: you know we were talking about a delay for supercedent... I wonder if we could make one that just delays (up to a window size) as long as there's stuff in whatever pipeline feeds it... so like.. make promote wait to start jobs if there are other things in the gate. | 18:52 |
| *** gmann is now known as gmann_afk | 18:53 | |
| fungi | that would require some additional coupling between those pipelines which zuul doesn't currently know, right? | 18:55 |
| fungi | at the moment (at least in opendev's deployment) gate and promote pipelines are triggered by independent external events | 18:55 |
| mordred | there are internal zuul events though - maybe that's a mechanism that could be leveraged somehow? | 18:56 |
| fungi | zuul reports success and then hits submit in code review, end of transaction. later zuul gets an event from the code review system saying a change merged and it starts running jobs for that | 18:56 |
| fungi | so yes, maybe in a direct-push scenario there would be internal event equivalents zuul could draw stronger conclusions about | 18:58 |
| fungi | otherwise you'd need additional configuration to tell it about the relationship between those pipelines | 18:58 |
| fungi | not saying it's impossible, just that it's something which would need to be manually defined not something zuul can easily infer on its own | 19:01 |
| fungi | so you could have a config option on the promote pipeline which says don't activate new items until there are no items for the same project+branch in the gate pipeline | 19:02 |
| clarkb | SpamapS: fungi mordred opendev addresses that with gearman priorities | 19:03 |
| fungi | basically, yeah | 19:03 |
| clarkb | we set the highest priority as the end of the chain | 19:03 |
| clarkb | and decrease as you work back to developer keyboards | 19:03 |
| corvus | nodepool priorities, but yeah | 19:03 |
| fungi | though i think in this case it's less a matter of priority and more a matter of avoiding resource waste | 19:03 |
| clarkb | oh right its zk now | 19:03 |
| clarkb | fungi: ya I think if you invert the priority direction you would ensure that you only did release type stuff after all the development type stuff has slowed down | 19:04 |
| clarkb | which would give you an approximation of the batching SpamapS wants I think | 19:04 |
| fungi | SpamapS seems to want to avoid doing a build in promote which is just going to just be obsoleted minutes later | 19:04 |
| fungi | but that might be orthogonal to priority | 19:04 |
| fungi | it might actually be very high priority to run the promote jobs as soon as it's clear there's a pause for that project+branch in incoming merges | 19:05 |
| SpamapS | That seems like it would only work at scale. | 19:06 |
| SpamapS | Small scale, it wouldn't really make much difference. | 19:06 |
| clarkb | ya would depend on available resources vs demand | 19:06 |
| clarkb | if you're well covered on the resource front it wouldn't make much difference | 19:06 |
| fungi | also, correct me if i'm wrong, but it sounds like you have either limited resources available for the promote builds or they take a significant resource volume/time to run? | 19:07 |
| fungi | if so, avoiding extra unwarranted runs there could be a significant efficiency boost/cost savings | 19:08 |
| *** sshnaidm has joined #zuul | 19:09 | |
| clarkb | my initial impression on that is this is what git tags are for | 19:09 |
| clarkb | if you need to make a judgement call on deployment costs then give a human that ability | 19:09 |
| fungi | that's certainly also a good option | 19:18 |
| clarkb | my worry about the automated version of that is starvation of the release pipeline. However, maybe it has a timeout where it runs every 4 hours regardless of input states | 19:21 |
| clarkb | and will wait for inputs to process otherwise | 19:21 |
| *** tosky has quit IRC | 19:21 | |
| *** hashar has joined #zuul | 19:44 | |
| *** pcaruana has quit IRC | 20:19 | |
| *** EmilienM is now known as EmilienM|mtg | 21:10 | |
| *** EmilienM|mtg is now known as EmilienM | 21:15 | |
| *** rfolco has quit IRC | 21:21 | |
| *** Goneri has quit IRC | 21:27 | |
| SpamapS | fungi: promote jobs poke running infrastructure for us... the less poking, the less false alerts. | 21:35 |
| SpamapS | it's not a big deal at all | 21:36 |
| SpamapS | and we use a release process that prevents it from happening a lot in parallel | 21:36 |
| SpamapS | just noticed a promote job running in parallel with 3 gate jobs and realized it was going to run 2-3 more times for no good reason. | 21:37 |
| * Shrews pokes SpamapS in the eyes in parallel | 21:37 | |
| fungi | well, i mean, his eyes *are* in parallel last i saw him | 21:37 |
| Shrews | fungi: he clearly hadn't been drinking yet then | 21:38 |
| SpamapS | https://gph.is/2igf8H0 | 21:38 |
| Shrews | :) | 21:38 |
| *** hashar has quit IRC | 21:39 | |
| mordred | SpamapS: I think I'm hungry because I totally thought you were talking about poké at first | 21:53 |
| corvus | should the google cloud google compute engine driver be called "gcloud" "google" or "gce"? | 21:53 |
| mordred | (which isn't spelled that way - but that's the best way I could think to distinguish in this case) | 21:53 |
| mordred | corvus: I kinda think gce | 21:53 |
| corvus | (yes, this means i'm almost done and only have "naming" left to deal with) | 21:53 |
| corvus | (ie, the hard problems) | 21:54 |
| mordred | corvus: because I imagine we could maybe grow a gke driver in the future too | 21:54 |
| corvus | yeah, that seems extremely likely | 21:54 |
| corvus | incidentally, i did take a look at the azure driver, and i don't think it's a slam-dunk for using the new simple task manager thing i've written. i think it's good for google and aws, but azure shares aspects of multiple resource creation with the openstack driver, so it's not a great fit right now. | 21:58 |
| corvus | but even that is nice, because we could start to think about how to reduce duplication between openstack and azure next. | 21:59 |
| mordred | corvus: neat | 21:59 |
| *** aluria has quit IRC | 22:02 | |
| corvus | by the way, typing "google cloud foo" into the firefox search bar is fun | 22:04 |
| mordred | corvus: I cannot imagine that frequently works | 22:04 |
| corvus | apparently firefox thinks users like to type "google foo" when they want to search for "foo", so it drops the "google". | 22:06 |
| corvus | so i have to add it back in | 22:06 |
| corvus | which more or less means i've been typing "google" a LOT the past 2 days. | 22:06 |
| mordred | corvus: you could probably write a firefox extension ... | 22:06 |
| *** bjackman has joined #zuul | 22:19 | |
| SpamapS | mmmmm poké | 22:21 |
| *** bjackman has quit IRC | 22:22 | |
| *** bjackman has joined #zuul | 22:23 | |
| mordred | SpamapS: ikr? | 22:24 |
| mordred | SpamapS: you're wondering why that's now what you're eating right now aren't you? | 22:25 |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: Add Google Cloud provider https://review.opendev.org/698342 | 22:28 |
| corvus | i think that's gtg | 22:28 |
| *** gmann_afk is now known as gmann | 22:29 | |
| corvus | SpamapS: ^ i looked at gce and the aws driver and found some commonalities; i think we can update the aws driver to use that framework and share a lot of code | 22:29 |
| corvus | oh i forgot to finish the rename | 22:30 |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: Add Google Cloud provider https://review.opendev.org/698342 | 22:33 |
| SpamapS | mordred: yes. Stupid yogurt. I want some fish and rice. | 22:34 |
| corvus | the interesting bit of that, from a "what does a simple driver look like" is in nodepool/driver/gce/adapter.py | 22:34 |
| SpamapS | corvus: that does not surprise me. | 22:34 |
| mordred | corvus: yah - gce.adapter reads really nice | 22:34 |
| corvus | the biggest boilerplate now is config objects; i think we can do a lot better with those | 22:35 |
| corvus | but this seemed like a good place to draw the line :) | 22:35 |
| corvus | also, if folks want, i can easily split that into 2 changes, one to add the framework, then one for the gce driver | 22:36 |
| *** bjackman has quit IRC | 22:36 | |
| *** bjackman has joined #zuul | 22:37 | |
| *** bjackman has quit IRC | 22:38 | |
| *** bjackman has joined #zuul | 22:38 | |
| mordred | corvus: I don't think it's too bad to review as is | 22:41 |
| *** rfolco has joined #zuul | 22:46 | |
| *** bjackman has quit IRC | 22:47 | |
| *** rfolco has quit IRC | 22:50 | |
| *** rfolco has joined #zuul | 23:01 | |
| *** rfolco has quit IRC | 23:06 | |
| *** dmsimard has quit IRC | 23:07 | |
| *** dmsimard has joined #zuul | 23:08 | |
| *** SotK has quit IRC | 23:09 | |
| *** SotK has joined #zuul | 23:09 | |
| *** dmellado has quit IRC | 23:09 | |
| *** fdegir has quit IRC | 23:09 | |
| *** sugaar has quit IRC | 23:10 | |
| *** fdegir has joined #zuul | 23:10 | |
| *** sugaar has joined #zuul | 23:10 | |
| *** irclogbot_3 has quit IRC | 23:11 | |
| *** sshnaidm is now known as sshnaidm|off | 23:11 | |
| *** dmellado has joined #zuul | 23:11 | |
| *** irclogbot_0 has joined #zuul | 23:13 | |
| *** rfolco has joined #zuul | 23:15 | |
| *** saneax has joined #zuul | 23:22 | |
| openstackgerrit | Ian Wienand proposed zuul/nodepool master: Also build sibling container images https://review.opendev.org/697393 | 23:37 |
| openstackgerrit | Ian Wienand proposed zuul/nodepool master: Add container functional test https://review.opendev.org/693464 | 23:37 |
| *** rfolco has quit IRC | 23:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!