*** lennyb has quit IRC | 02:04 | |
*** lennyb has joined #zuul | 02:06 | |
tobiash | SpamapS: this was the fix for the stream did not terminate problem: https://review.openstack.org/#/c/491027/2 | 04:25 |
---|---|---|
tobiash | SpamapS: so maybe you don't have this yet or found an additional edge case where this still occurs | 04:26 |
SpamapS | tobiash: I have that commit. | 05:44 |
SpamapS | Deployed up to master from Friday at this point. | 05:44 |
tobiash | SpamapS: hm, then you probably found a new edge case where this fix didn't work | 05:45 |
tobiash | SpamapS: wait, master or feature/zuulv3? | 05:45 |
SpamapS | Yeah I'm not seeing any errors in the logs around the same time. | 05:45 |
SpamapS | tobiash: feature/zuulv3 ;) | 05:45 |
tobiash | ;) | 05:45 |
SpamapS | soon to be master I Hope | 05:45 |
tobiash | don't know what the plans are for branching | 05:45 |
SpamapS | Yeah it's something to think about after cutover | 05:47 |
*** Shrews has quit IRC | 06:05 | |
*** harlowja has quit IRC | 06:05 | |
*** Shrews has joined #zuul | 06:05 | |
*** mnaser has quit IRC | 06:12 | |
*** mnaser has joined #zuul | 06:30 | |
*** xinliang has quit IRC | 07:02 | |
*** xinliang has joined #zuul | 07:15 | |
*** hashar has joined #zuul | 07:18 | |
*** xinliang has quit IRC | 07:42 | |
*** xinliang has joined #zuul | 07:42 | |
*** xinliang has quit IRC | 07:42 | |
*** xinliang has joined #zuul | 07:42 | |
*** hashar has quit IRC | 08:36 | |
*** hashar has joined #zuul | 08:37 | |
*** electrofelix has joined #zuul | 08:45 | |
*** bhavik1 has joined #zuul | 10:30 | |
*** bhavik1 has quit IRC | 10:33 | |
*** jkilpatr has quit IRC | 10:42 | |
openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: WIP: Honor cloud quotas before launching nodes https://review.openstack.org/503838 | 11:00 |
openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Don't fail on quota exceeded https://review.openstack.org/503051 | 11:00 |
openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Make max-servers optional https://review.openstack.org/504282 | 11:00 |
openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Support cores limit per pool https://review.openstack.org/504283 | 11:00 |
openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Support ram limit per pool https://review.openstack.org/504284 | 11:00 |
*** jkilpatr has joined #zuul | 11:15 | |
*** dkranz has joined #zuul | 12:56 | |
*** hashar_ has joined #zuul | 13:06 | |
*** hashar has quit IRC | 13:08 | |
dmsimard | mordred, jeblair: are we making sure that the executor can't connect to itself through it's public IP ? doesn't seem covered here: https://github.com/openstack-infra/zuul/blob/feature/zuulv3/zuul/ansible/action/normal.py#L38 | 13:45 |
mordred | dmsimard: nope, we are not | 14:14 |
mordred | dmsimard: connecting to itself shouldn't be an issue though, as the executor should not have an ssh key that is authorized to any users on the executor | 14:14 |
dmsimard | mordred: right, so context is we were looking for the right way of connecting to containers which might be hosted on localhost | 14:15 |
dmsimard | mordred: there was this "workaround" but the proper fix is probably to have the driver handle the executor restrictions somehow | 14:15 |
mordred | dmsimard: well, I do not think it's a problem to have them ssh to the container on localhost - the first thing we do in the base job is swap the ssh keys out | 14:18 |
mordred | dmsimard: so it shouldn't be an issue to use containers on localhost (obviously you'll need ports :) ) | 14:19 |
dmsimard | mordred: right now it is because the check (linked from normal.py) is fairly naive in that it only checks for localhost or 127.0 | 14:22 |
dmsimard | so if I try to connect on a localhost container on port 50000, it will still deny local executor execution | 14:23 |
mordred | oh - right - sorry - still waking up ... | 14:23 |
mordred | dmsimard: so - for that, I believe you'll want to pass either the public or private ip of the machine with a port if you want to use a container that's also hosted on the local machine | 14:24 |
mordred | using localhost as the ip of that will not work | 14:24 |
mordred | the localhost entry in a catalog is 'special' | 14:24 |
dmsimard | mordred: right, that's what I meant by "working around" with the public ip | 14:24 |
dmsimard | feels kind of dirty though | 14:25 |
mordred | well - overall I think it's more correct. in the general case, there's no way for nodepool to know that a given container will be co-located on the same host as an executor | 14:26 |
mordred | while it might work as an optimization in the case where it's an AIO setup - from a plumbing perspective I think it would be extra complexity to have nodepool try to sometimes provide localhost as the ip and sometimes the actual IP | 14:26 |
mordred | whereas if nodepool just always provides the non-localhost IP, it should work with both AIO and multi-node setups | 14:27 |
dmsimard | makes sense | 14:32 |
mordred | dmsimard: now, in addition to that, at SOME point we may want to figure out connection=docker for using docker connection rather than ssh ... and I don't think our action plugins support doing that currently | 14:38 |
dmsimard | mordred: right, I discussed that with tristanC -- there are different connection plugins (not just 'docker') | 14:38 |
mordred | yah | 14:38 |
dmsimard | https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/connection | 14:39 |
mordred | dmsimard: we're likely to get to connection=winrm before connection=docker since windows is a thing tobiash is working towards right now | 14:39 |
dmsimard | technically, is there anything preventing that from working already ? | 14:39 |
dmsimard | could I just set a 'ansible_connection: winrm' var ? | 14:39 |
mordred | dmsimard: we explicitly disallow doing that | 14:40 |
dmsimard | oh | 14:40 |
mordred | dmsimard: if you try any connection other than ssh right now it will break | 14:40 |
tobiash | dmsimard: nodepool tells zuul the connection in the windows patch stack | 14:40 |
dmsimard | cool | 14:40 |
tobiash | dmsimard: what's missing yet is a patch in zuul to honor that | 14:40 |
tobiash | but that should be easy | 14:40 |
dmsimard | mordred: so re: last night's trusted thing | 14:40 |
tobiash | just hadn't time for this yet | 14:41 |
dmsimard | mordred: you're saying not everyone will be able to, say, add a job to the keystone project ? | 14:41 |
dmsimard | mordred: where's the boundary ? only trusted projects may add a job to a project that isn't their own ? | 14:42 |
mordred | tobiash: yah - as part of that we'll need to whitelist the winrm connection plugin I think | 14:47 |
mordred | dmsimard: yes. only trusted projects | 14:47 |
mordred | dmsimard: this goes nicely with the thing jeblair was talking about with making the 'name' field in the project pipeline definition optional | 14:48 |
mordred | dmsimard: since for non-trusted projects, there is only one valid value for it | 14:48 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Add strip_branch_ref compat option https://review.openstack.org/505290 | 14:48 |
dmsimard | mordred: ok, and the trusted projects are defined where ? zuul.conf on the nodes ? | 14:50 |
mordred | dmsimard: main.yaml | 14:50 |
mordred | dmsimard: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/main.yaml | 14:50 |
mordred | dmsimard: sorry - 'config-projects' | 14:50 |
dmsimard | mordred: TIL about zuul/main.yaml | 14:50 |
mordred | dmsimard: it's the place we tell zuul about tenants and what projects exist | 14:51 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: configloader: don't use path in SourceContext comparaison https://review.openstack.org/505293 | 14:53 |
tobiash | mordred: thanks for this hint, I would have been run into this for sure :) | 14:55 |
openstackgerrit | Merged openstack-infra/zuul master: Add strip_branch_ref compat option https://review.openstack.org/505290 | 14:59 |
jlk | o/ | 15:35 |
SpamapS | tobiash: I have some interest here to run against Windows test nodes too, so I may be up for helping you in a month or so. | 15:37 |
tobiash | SpamapS: I'll probably have this running this or next week. Already have nodepool booting windows nodes into ready state. The zuul connection should be (hopefully) the last missing peace :) | 15:49 |
tobiash | S | 15:51 |
tobiash | s/peace/piece/ | 15:52 |
jlk | This week I'm poking at docker being in swarm mode, so that you can ask a pile of docker hosts to "make me a container" and it'll go find a place to put one. Then get details about it to use the docker connection plugin along with docker_host info to do ansible things in the remote container. | 15:52 |
jlk | with the idea that "making the docker swarm" is outside of nodepools duties, but you just feed it a swarm endpoint (much like a cloud endpoint). | 15:52 |
SpamapS | tobiash: cool | 15:53 |
SpamapS | jlk: I know k8s adds another level of complexity... but.. if you were to start there... I would have more reason to help. :) | 15:53 |
jlk | jamielennox is thinking down that path | 15:54 |
jlk | multi-tenancy is going to be weird there, according to him | 15:54 |
SpamapS | sobeit | 15:54 |
SpamapS | multi-tenancy is weird in openstack too.. since zuul has multiple tenants but nodepool still just has one project in openstack. | 15:55 |
jlk | sure, but consumers don't get an openstack API to play with | 15:55 |
SpamapS | AFAICT, the tenants in Zuul are for visibility grouping, not access control. | 15:55 |
jlk | I guess maybe the better question is, what should consumers be exposed when using nodepool with k8s? | 15:56 |
SpamapS | Since all tenants can request all node labels. | 15:56 |
jlk | should they just get direct access to a container running in k8s? | 15:56 |
jlk | should they get some sort of k8s interface to launch their service? | 15:56 |
tobiash | Label restrictions for tenants is also part of my roadmap some time in future | 15:57 |
SpamapS | jlk: I think the playbooks should get access to a k8s with the desired images if the job has a k8s node type. | 15:59 |
jlk | I think that's the problem, if you have access to a k8s, you have access to other job's k8s containers too | 15:59 |
jlk | because afaik k8s doesn't do multi-tenancy in that way | 16:00 |
jlk | but I'm just echoing what jamielennox was finding, so I'm likely getting it wrong | 16:00 |
SpamapS | k8s has RBAC's, but you may be right, the role that can spin things up may be able to list and mess with others | 16:00 |
SpamapS | jlk: actually, if the secrets for the k8s are only exposed to trusted playbooks, this shouldn't be a problem. | 16:03 |
SpamapS | let the untrusted pre playbook write out the desired pods, and trusted playbooks do the actual k8s work. | 16:04 |
*** isaacb has joined #zuul | 16:04 | |
jlk | that would be ... hrm. | 16:05 |
SpamapS | Well first we have to ask ourselves why we want containers. | 16:05 |
SpamapS | The answer, I think, is density. | 16:05 |
jlk | resource packing. | 16:05 |
jlk | speed | 16:05 |
SpamapS | So I think it's entirely fine to suggest that if users want faster tests and more resources to run them, they give up some control. | 16:06 |
SpamapS | This isn't for testing how your thing works with k8s. | 16:06 |
SpamapS | For that, spin up a k8s in vms. | 16:06 |
jlk | nod | 16:06 |
SpamapS | But having it be able to consume a k8s means I can use my fairly significant sized CaaS to run a lot more tests in a Zuul here at GoDaddy. | 16:06 |
SpamapS | (CaaS == Containers aaS) | 16:07 |
jlk | yeah | 16:07 |
jlk | so k8s is a means to a container, not a means to test k8s or k8s like deployments | 16:07 |
jlk | you won't do k8s things, you'll just consume containers out of it. | 16:07 |
*** hashar_ is now known as hashar | 16:08 | |
SpamapS | Mostly yes. | 16:08 |
SpamapS | I think we can do some k8s things, but they're mostly just docker-swarmy things running through k8s because k8s is going to be a lot more common than swarm IMO. | 16:08 |
jlk | yeah, that's reasonable. That's a shortcut to using something like gcp or azure too | 16:08 |
SpamapS | Precisely. | 16:09 |
SpamapS | That said, swarm makes a lot more sense for one-off short lives things. | 16:09 |
SpamapS | because zomg simple. | 16:09 |
jlk | yeah... :) | 16:09 |
SpamapS | And there are likely others that are somewhere in between. | 16:09 |
jlk | although, first struggle point, get the daemon listening on the tcp port and let me remotely connect to it. | 16:09 |
jlk | bahaha. 69.whatever is not the same as 169.whatever | 16:20 |
dmsimard | jeblair: once the gerrit dust has settled, I wanted to ask about logstash for v3 jobs. It doesn't look like logs are sent to logstash yet so I wanted to see if it was an issue or the logstash work was not yet finished. | 16:24 |
*** isaacb has quit IRC | 16:45 | |
jlk | limited success! | 16:47 |
jlk | ansible -i hosts docker -m raw -a "executable=ash ls" -vvvv | 16:48 |
jlk | <5e4f9204f794> EXEC ['/usr/local/bin/docker', u'-H', u'tcp://169.44.161.54:2375', 'exec', '-i', u'5e4f9204f794', u'/bin/sh', '-c', u'ash -c ls'] | 16:48 |
jlk | 5e4f9204f794 | SUCCESS | rc=0 >> | 16:48 |
jlk | I seem to recall that we have some static nodes in our zuul v3 configuration. Where was that at? | 17:06 |
jlk | blah, I think I remembered wrong. | 17:27 |
*** olaph has quit IRC | 17:30 | |
jeblair | dmsimard: i left it at "maybe it works now" but haven't followed up to see if it does, or if not, what the problems are. will probably involve checking logstash processer server logs (root) so i'll have to poke at it in a little while. | 17:30 |
jlk | jeblair: at this time, we do not have support for "static" nodes, do we? | 17:31 |
mordred | jeblair, dmsimard, jlk, SpamapS, Shrews, jamielennox: today is fix-gerrit-upgrade day for some of us - but it's worth noting that ansible 2.4 was released today. if anyone has time, it might be worthwhile to start figuring out what in 2.4 may have broken things for us | 17:31 |
mordred | jlk: not today - there are patches proposed in nodepool, but we've been deferring dealing with them til post rollout | 17:32 |
*** olaph has joined #zuul | 17:32 | |
mordred | jlk, SpamapS: I'd love to chat about the swarm/docker/k8s stuff once gerrit is less on fire | 17:33 |
jlk | sounds good. | 17:34 |
jeblair | also, swarm/docker/k8s stuff is on our post-transition roadmap, but it's not exactly at the top of the list. i'd love to talk about it too, but i'd also like to get v3 out the door first. | 17:34 |
jlk | agreed. | 17:35 |
jlk | this is "scratching a personal interest" not a "lets shove this in" | 17:35 |
jeblair | whew, cool :) | 17:35 |
jeblair | (and i realize the status of the post-transition roadmap is "jeblair is to write it up with more words and send it out for discussion"; that's probably not going to happen today though :) | 17:36 |
jlk | also it's kind of "spinning my wheels until gerrit fire is out and we have a roadmap" thing ;) | 17:37 |
jeblair | ++ | 17:37 |
*** electrofelix has quit IRC | 17:48 | |
*** harlowja has joined #zuul | 17:49 | |
Shrews | mordred: yeah, i was going through the 2.4 change list earlier. didn't see anything obvious. | 18:01 |
Shrews | not sure how complete that list was (internal release announcement) | 18:02 |
* Shrews will poke further | 18:02 | |
Shrews | CHANGELOG.md is likely more complete | 18:04 |
mordred | Shrews: I was also thinking that proposing a patch to bump the ansible requirement might break some tests | 18:08 |
mordred | Shrews: AND - we should probably audit the plugins dirs in the new release to make sure that a) we have specific action/filter plugin things for any new action/filter plugins that we want to block - and b) that we add the new plugin types to the list of directories to look for in blocking people from adding plugins to their in-repo content | 18:10 |
Shrews | mordred: yep. already on #1 | 18:14 |
openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: DNM: Test Ansible 2.4 https://review.openstack.org/505354 | 18:15 |
Shrews | there is a new stderr callback | 18:16 |
SpamapS | jeblair: for me it may be "the only way I get to play with zuul" so it may raise in priority for me. ;) | 18:21 |
jeblair | SpamapS: i understand, though i hope that as a team we can find a balance so that we get fundamental work done. if we aren't able to actually put together a basic functioning v3 that other folks can use, then no one will get to work on it :( | 18:26 |
jeblair | we need to be in a place where this isn't an either/or choice -- that we have a roadmap and we all agree on it, and are all working in parallel | 18:27 |
jeblair | i just don't think we're there yet, nor will we be until we have things like new-user documentation, or first-class github support | 18:28 |
openstackgerrit | Timo Tijhof proposed openstack-infra/zuul master: Status: Remove use of deprecated jQuery jqXHR `complete` method https://review.openstack.org/505366 | 18:42 |
openstackgerrit | Timo Tijhof proposed openstack-infra/zuul master: Status: Don't toggle panel when clicking patch link https://review.openstack.org/505368 | 18:46 |
jeblair | these ^ would be good to port to v3 if anyone has a moment | 18:46 |
Shrews | jeblair: i'll grab 'em | 18:49 |
openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Status: Remove use of deprecated jQuery jqXHR `complete` method https://review.openstack.org/505369 | 18:53 |
openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Status: Don't toggle panel when clicking patch link https://review.openstack.org/505370 | 18:53 |
dmsimard | jeblair: re: logs -- I think we'll need to troubleshoot things, yes. Searching a build_change after a review that is only zuul v3 does not pull up anything. | 19:00 |
dmsimard | mordred: 2.4 -- I had to cut a dot release for ara to pin Ansible<2.4. I was optimistic that I could get it fixed in time but nope. | 19:01 |
dmsimard | I know what the first problem is and know how to fix it, just haven't got around to it yet. I don't know yet if there are any problems hidden underneath. | 19:02 |
mordred | dmsimard: cool - sounds like something we should be able to fix fairly easily once we get a second | 19:02 |
dmsimard | I suppose we might want to rebase our forks of the different modules/plugins we have in zuul v3 at the very least | 19:03 |
openstackgerrit | Merged openstack-infra/zuul master: Status: Remove use of deprecated jQuery jqXHR `complete` method https://review.openstack.org/505366 | 19:04 |
openstackgerrit | Merged openstack-infra/zuul master: Status: Don't toggle panel when clicking patch link https://review.openstack.org/505368 | 19:04 |
jlk | Yeah I kind of wonder if wouldn't make sense to maintain a patch file (git format-patch) of our changes to the plugins/modules/etc we patch from Ansible, so that we can more easily port those changes to newer versions. | 19:06 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Use publish-docs-draft base job for docs-draft publishers https://review.openstack.org/504624 | 19:12 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Removed unused 'status: ' string from log line https://review.openstack.org/505378 | 19:12 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Emit shell instead of script tasks https://review.openstack.org/505379 | 19:12 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Omit some jobs from shared queue calculation https://review.openstack.org/505380 | 19:12 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Status: Remove use of deprecated jQuery jqXHR `complete` method https://review.openstack.org/505369 | 19:14 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Status: Don't toggle panel when clicking patch link https://review.openstack.org/505370 | 19:14 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Deal with link-logs macro https://review.openstack.org/505387 | 19:38 |
mordred | jlk: yah - although I'm _hoping_ I can get time to get stuff upstreamed during 2.5 and maybe stop having a local fork | 20:00 |
jlk | If nobody is working on porting the patches forward, I can take a peek. | 20:01 |
jlk | Shrews: are you forward patching things? | 20:01 |
mordred | jlk: I may take you up on that - step one is I need to write a spec | 20:01 |
mordred | that summarizes the stuff we talked about in london and proposes a plan for it | 20:02 |
Shrews | jlk: just the two above | 20:02 |
jlk | yeah I wasn't talking about taking them upstream, just keeping our patched versions updated with ansible release | 20:02 |
Shrews | jlk: i was going to look at the ansible module diffs next, but getting close to EOD for me if you want to do that | 20:02 |
jlk | okay, I've got some work hours yet, so I'll take a few on. | 20:03 |
*** jesusaur has quit IRC | 20:08 | |
*** jesusaur has joined #zuul | 20:11 | |
*** jkilpatr has quit IRC | 20:18 | |
mordred | Shrews, jlk: have fun with those! that's our lovely log-streaming hacks | 20:21 |
jlk | Shrews: dmsimard: mordred: et al, lets coordinate https://etherpad.openstack.org/p/zuul-ansible-2.4 | 20:23 |
pabelanger | +1 | 20:33 |
*** jkilpatr has joined #zuul | 20:42 | |
jlk | which version of Ansible have we been using? | 20:55 |
jlk | v2.3.2.0-1 ? | 20:55 |
mordred | yah. whatever the latest 2.3 is | 20:56 |
mordred | there's a version cap in zuul's requirements.txt | 20:56 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul-sphinx master: Update exception message to include directories https://review.openstack.org/505400 | 20:58 |
jlk | yeah a cap, but I wasn't sure if there was a upper-limits coming into play somewhere | 20:59 |
jlk | hrm. | 20:59 |
*** dkranz has quit IRC | 21:01 | |
jlk | oh, I get it now | 21:01 |
jlk | some of our plugins are doing magic to import the upstream plugin, then we do some extra stuff and eventually super call the upstream plugin. | 21:01 |
mordred | jlk: yah. that should be _most_ of them | 21:31 |
jlk | done digging through lookups/plugins/modules in our tree. A few could use some updates, and a few need a a fair amount of inspection. | 21:31 |
jlk | going afk for a bit | 21:31 |
mordred | cool | 21:31 |
mordred | jlk: thanks! | 21:31 |
jlk | de nada | 21:32 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Add disabled network action plugins for 2.4 https://review.openstack.org/505419 | 21:47 |
*** hashar has quit IRC | 21:59 | |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Disable action and lookup plugins from 2.4 https://review.openstack.org/505419 | 22:03 |
mordred | jlk, Shrews: ^^ that should be all the new stuff | 22:04 |
mordred | (the new added plugins, not the stuff jlk already has listed) | 22:05 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Port in changes from ansible 2.4 command module https://review.openstack.org/505430 | 22:29 |
mordred | Shrews, jlk: ^^ I stole command - there's no need to assault anybody else with ugly mordred hacks | 22:30 |
*** openstackgerrit has quit IRC | 22:47 | |
jlk | mordred: LOL, no worries. | 23:14 |
jlk | mordred: did you mean to add .pyi files? | 23:20 |
jlk | oh hrm, I guess so. | 23:24 |
jlk | reading when one was added, that's... gross | 23:24 |
clarkb | thats how you do type identification righ? | 23:31 |
jlk | yeah, but these are blank files | 23:32 |
pabelanger | okay, I have stopped nl02.o.o in preperation for landing our new nodepool-launcher configuration in the morning | 23:49 |
pabelanger | dmsimard: do you still need access to the held nodes in rax-ord? | 23:51 |
dmsimard | No, told clarkb to release them a while back. They were helpful in understanding the multi node issues. | 23:51 |
pabelanger | k | 23:51 |
*** openstackgerrit has joined #zuul | 23:54 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: add /tenants route https://review.openstack.org/503268 | 23:54 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: add /{tenant}/status route https://review.openstack.org/503269 | 23:55 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: add /{tenant}/jobs route https://review.openstack.org/503270 | 23:55 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: add /{tenant}/builds route https://review.openstack.org/466561 | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!