| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-19 | |||
| 18:08:36 | sean-k-mooney | dims: are they all required? | |
| 18:09:16 | sean-k-mooney | jaypipes: will the filter change need to be made to nova or os-vif | |
| 18:09:16 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 18:09:17 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 18:09:18 | openstackgerrit | Jay Pipes proposed openstack/nova: pci: add uuid field to PciDevice object https://review.openstack.org/414768 | |
| 18:09:18 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: integrate ProviderTree to report client https://review.openstack.org/415921 | |
| 18:09:19 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: SRIOV PF devices as child providers https://review.openstack.org/414769 | |
| 18:09:19 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: adds ProviderTree for nested resources https://review.openstack.org/415920 | |
| 18:09:20 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 18:09:20 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: add nested resource providers https://review.openstack.org/377138 | |
| 18:09:40 | jaypipes | sean-k-mooney: os-vif. which means becaus eof the non-client freeze we need to do it today. | |
| 18:09:58 | jaypipes | sean-k-mooney: shouldn't be a hard fix. will work on it shortly. | |
| 18:10:02 | jaypipes | it's just a py35 thing. | |
| 18:10:21 | dims | sean-k-mooney : y, nothing too big in there, all small stuff. very close 1 failure left (http://logs.openstack.org/09/421209/15/experimental/gate-tempest-dsvm-nova-py35-ubuntu-xenial/b47de57/logs/testr_results.html.gz) | |
| 18:10:23 | sean-k-mooney | yes but it means we need to do a 1.4.1 release also correct | |
| 18:11:57 | sean-k-mooney | dims: no reason other then if i wanted to replicate locally its a little trickyer to recreate | |
| 18:13:48 | openstackgerrit | Vladik Romanovsky proposed openstack/nova: Adding vlans filed to Device tagging metadata https://review.openstack.org/405951 | |
| 18:13:49 | openstackgerrit | Vladik Romanovsky proposed openstack/nova: libvirt: expose virtual interfaces with vlans to metadata https://review.openstack.org/405954 | |
| 18:19:19 | jaypipes | dims: so you're already working on a fix for that os-vif thing? or should I do that? | |
| 18:20:04 | dims | jaypipes : please go ahead. | |
| 18:20:50 | jaypipes | dims: you got it :) | |
| 18:21:10 | dims | thanks much jaypipes ! | |
| 18:24:09 | openstackgerrit | Eric Fried proposed openstack/nova: Introduce base PowerVM driver (console) https://review.openstack.org/409402 | |
| 18:26:40 | openstackgerrit | Eric Fried proposed openstack/nova: WIP(4): Introduce base PowerVM driver (cfg drv) https://review.openstack.org/409404 | |
| 18:50:03 | jaypipes | dims: did you have a bug report about this os-vif thing? | |
| 18:50:14 | jaypipes | dims: if not, I'll add one. | |
| 18:50:38 | dims | jaypipes : no i have not added one | |
| 18:51:19 | jaypipes | dims: k, no problemo. | |
| 18:51:35 | dims | starting hard at logs :) | |
| 19:21:14 | mriedem | what os-vif issue do we have? | |
| 19:28:50 | jaypipes | mriedem: it's a py35 thing... | |
| 19:28:56 | jaypipes | http://logs.openstack.org/09/421209/16/experimental/gate-tempest-dsvm-nova-py35-ubuntu-xenial/15a4fc7/logs/screen-n-cpu.txt.gz?level=ERROR | |
| 19:29:13 | mriedem | oh that's known | |
| 19:29:20 | mriedem | oh wait no it's not | |
| 19:29:51 | mriedem | but, that's also the experimental queue so not blocking us right now | |
| 19:29:59 | mriedem | and therefore i will put my head in the sand | |
| 19:30:54 | openstackgerrit | Bob Ball proposed openstack/nova: Use physical utilisation for cached images https://review.openstack.org/353862 | |
| 19:30:56 | jaypipes | mriedem: :) | |
| 19:32:01 | mriedem | and for whatever reason https://review.openstack.org/#/c/422709/ is taking forever to land | |
| 19:36:33 | sean-k-mooney | mriedem: well looking at zull it is currently in the intergrated gate queue | |
| 19:37:33 | sean-k-mooney | mriedem: its being cogated with quite a few other patches but should merge soonish | |
| 19:38:52 | sdague | mriedem: we found a zuul bug | |
| 19:38:56 | sdague | or... limitation | |
| 19:39:05 | sdague | it's more fair to call it a limitation | |
| 19:39:54 | sean-k-mooney | sdague: mind shareing? whats the limitation? | |
| 19:40:48 | sdague | sean-k-mooney: in order to match jgit's merge behavior, zuul is using a git merge strategy that falls over after 6 way merge | |
| 19:41:12 | openstackgerrit | Jay Pipes proposed openstack/os-vif: Correct py27 assumption that filter() returns list https://review.openstack.org/422838 | |
| 19:41:14 | jaypipes | dims: ^^ | |
| 19:41:26 | sdague | which means when you get a whole stream of unchained commits eventually they merge fail | |
| 19:41:46 | sdague | requirements upper-constraints auto generated items fall into that category | |
| 19:42:11 | sean-k-mooney | sdague: ah ok | |
| 19:42:41 | sean-k-mooney | and im guessing if we iterativly merged the patches instade of 6+ way merge it would break compaiblity with jgit | |
| 19:43:20 | sdague | sean-k-mooney: yeh, it would instead look like it was going to pass, get to top of queue, and gerrit would fail it | |
| 19:43:29 | sdague | which used to happen | |
| 19:44:01 | sdague | this fails things in a few more situations though, so it's kind of a toss up as to when you get kicked in the pants | |
| 19:44:46 | sean-k-mooney | sdague: actully looking at the zull gate queue specifcally for the patch mriedem was interested in https://review.openstack.org/#/c/422709 | |
| 19:45:14 | sean-k-mooney | there are 2 other requirements changes in front of it that will cause the rest of the queue to restart when they merge | |
| 19:45:22 | sdague | no | |
| 19:45:40 | sdague | the symptom was a merge fail when it entered the gate queue | |
| 19:45:47 | sdague | so it was a black dot | |
| 19:45:49 | sean-k-mooney | is there any reason we currently allow multiple changes to the same repo to be cogated | |
| 19:46:06 | sdague | sean-k-mooney: as opposed to? | |
| 19:46:41 | sean-k-mooney | not starting the subsequent job until the first one passed or filed. | |
| 19:47:07 | sean-k-mooney | currentlyu we waste vms runing jobs that will be restarted when the first patch merges | |
| 19:47:33 | openstackgerrit | Sergey Nikitin proposed openstack/nova: do not merge https://review.openstack.org/422841 | |
| 19:47:35 | sdague | sean-k-mooney: no, we don't | |
| 19:47:48 | sdague | the merge is done early | |
| 19:47:54 | sdague | if it fails, no vms are started | |
| 19:48:30 | sean-k-mooney | if you go to http://status.openstack.org/zuul/ and filter on 422709 when the current top patch 422502 merges the requirements job belowit will be restarted | |
| 19:49:03 | sdague | sean-k-mooney: why do you think that it will be? | |
| 19:49:21 | sean-k-mooney | i just watch the q restart all jobs | |
| 19:49:30 | sdague | yeh, that's because top of gate failed | |
| 19:49:44 | sean-k-mooney | oh ok i tagut it passed sorry | |
| 19:50:04 | sdague | I'm pretty sure it's because top of gate failed | |
| 19:51:04 | sdague | https://review.openstack.org/#/c/292570/ just got a -2 10 minutes ago | |
| 19:51:06 | sean-k-mooney | i wasnet paying enough attention to note down which patch it was so not sure. i noticed that other patches merged and the queue did not resate so your proably correct in assuming that it failed | |
| 19:55:38 | dims | jaypipes : does "if dup_filter:" on an iterator work properly? | |
| 20:07:15 | jaypipes | dims: not sure... | |
| 20:07:22 | jaypipes | (and I need to run out for a couple hours...) | |
| 20:14:19 | sean-k-mooney | dims: it looks like an iterator over an empty list or full list both evaluate as true | |
| 20:15:50 | sean-k-mooney | dims: im not sure what the input to the lamda fuction is but if filter retruns an interator it will always enter the if dup_filter block | |
| 20:16:20 | dims | sean-k-mooney : so when we do a filter, immediately turn it into a list would work | |
| 20:22:43 | openstackgerrit | Timofey Durakov proposed openstack/nova: Make all datastamps formats equal https://review.openstack.org/421981 | |
| 20:24:28 | tdurakov | hi folks, who could review small fix for notification timestam formats? | |
| 20:27:39 | tdurakov | gibi: ping | |
| 20:52:03 | mriedem | nova meeting in 8 minutes | |
| 20:53:45 | jroll | omg I'm so excited | |
| 20:54:36 | tdurakov | mriedem: if you have a minute, could you please a patch above? | |
| 20:58:13 | mriedem | tdurakov: does that not require a change to the samples? | |
| 21:00:24 | tdurakov | mriedem: according to the previous run(see ps1) I'd say it doesn't(surprise!!!) | |
| 21:00:30 | tdurakov | at least for me | |
| 21:09:55 | slaweq | mriedem: hello, can You have a look on https://review.openstack.org/#/c/420176/ ? | |
| 21:09:58 | slaweq | thx in advance | |
| 21:23:13 | tdurakov | mriedem: so, for the that notifications fix... I assume there should be no notification versions bump, as object versions are remain the same, right? | |
| 21:27:08 | mriedem | tdurakov: well, the format on the thing getting sent has changed | |
| 21:28:37 | tdurakov | mriedem: what is the proper way to bump versions then? | |
| 21:31:31 | mriedem | tdurakov: i'm not sure in this case, and that's why i'm surprised the existing samples tests don't fail | |
| 21:31:40 | mriedem | btw there is a pep8 failure on that change | |
| 21:31:46 | tdurakov | already fixed | |
| 21:31:55 | tdurakov | will resubmit in a minute | |