| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-22 | |||
| 10:21:57 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for os-quota-classes endpoint instead of stevedore https://review.openstack.org/461641 | |
| 10:23:48 | openstackgerrit | jichenjc proposed openstack/nova master: Deprecate unused policy from policy doc https://review.openstack.org/465505 | |
| 11:17:25 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Should not allow security group from other project pass API layer check when booting https://review.openstack.org/466160 | |
| 11:21:35 | danpawlik | Morning. Does someone know, how to recheck only one CI like: Citrix XenServer CI (https://review.openstack.org/#/c/459753/) ? I don't want to make recheck. Thanks | |
| 11:26:21 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Use more specific asserts in tests https://review.openstack.org/466609 | |
| 11:37:53 | danpawlik | kashyap, mriedem: Hi. Can you review https://review.openstack.org/#/c/459753/ in free time ? Please :) | |
| 11:38:28 | kashyap | danpawlik: Will look in a bit; in the middle of something | |
| 11:44:51 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 11:44:51 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 11:59:30 | openstackgerrit | sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 11:59:30 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 11:59:31 | openstackgerrit | sahid proposed openstack/nova master: network: add command to configure trusted mode for VFs https://review.openstack.org/458513 | |
| 12:02:32 | openstackgerrit | sahid proposed openstack/nova master: libvirt: update the active migrations DS to support migration result https://review.openstack.org/409260 | |
| 12:02:34 | openstackgerrit | sahid proposed openstack/nova master: libvirt: ensure live-migration success https://review.openstack.org/409261 | |
| 12:18:19 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Update noVNC URL https://review.openstack.org/466710 | |
| 12:19:49 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Update noVNC URL https://review.openstack.org/466710 | |
| 12:21:51 | jaypipes | sdague, mdbooth, sfinucan: anyone remember a bug that was fixed in Nova (or elsewhere?) about predictable network interface names in guests? | |
| 12:22:39 | cdent | jaypipes: I very vaguely remember reading something about that, but not enough to do any real searching :( | |
| 12:23:13 | mdbooth | jaypipes: Not specifically. Did it involve assuming network interface names started with 'eth'? | |
| 12:23:22 | jaypipes | mdbooth: ya. | |
| 12:23:52 | jaypipes | mdbooth: googling for "persistent (or predictable) interface names nova openstack" yields nothing useful.. | |
| 12:24:11 | mdbooth | jaypipes: Any idea what code it would have touched? | |
| 12:25:53 | jaypipes | mdbooth: not sure... maybe the libvirt XML configurator code? | |
| 12:26:15 | jaypipes | mdbooth: or alternately maybe something around the network metadata stuff? | |
| 12:27:43 | mdbooth | jaypipes: commit 577174b025af9513aaba572d6965f9b0e0d1b3c1 maybe ? | |
| 12:30:00 | mdbooth | That looks like it might result in binding by mac address rather than name | |
| 12:30:06 | mdbooth | That looks very debian-specific. I wonder what that is... | |
| 12:32:56 | jaypipes | mdbooth: yeah, doesn't look like it.. | |
| 12:34:53 | mdbooth | jaypipes: Got a bug you're trying to fix, btw? | |
| 12:35:14 | sdague | jaypipes: I thought that was the whole vif device tags push | |
| 12:35:31 | jaypipes | mdbooth: nah, someone internally at Mirantis is complaining about it and I vaguely remembered it coming up about a year ago and was looking for more info. | |
| 12:36:00 | jaypipes | sdague: nah, that was more to identify physical networks that a vif was associated with, IIRC> | |
| 12:36:28 | jaypipes | artom: ^^ is my memory correct on that? | |
| 12:39:37 | sfinucan | jaypipes: Nothing off the top of my head, I'm afraid | |
| 12:41:49 | sdague | jaypipes: it's not really a solvable problem, device naming inside a guest is determined by the guest os, and different linux distros do it differently with hotplug rules | |
| 12:42:13 | sdague | you definitely need guest assist there | |
| 12:47:49 | efried | sdague https://review.openstack.org/#/c/419662/ you said, "The tests that are running on top of this are failing on these jobs, because the tempest timeout is too low (300s), so the sleep 600 is triggering a fail. We need that to be handled." | |
| 12:47:58 | efried | sdague Is that still an issue? I'm not seeing where that's happening. | |
| 12:49:44 | sdague | efried: I don't know, it's a pretty old comment on an old set of test failures | |
| 12:50:09 | efried | sdague Okay, wasn't sure if the failure was posted in the CI results on this change set, or... somewhere else. | |
| 13:02:40 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Fix ChanceScheduler returning a wrong node https://review.openstack.org/466725 | |
| 13:02:40 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455 | |
| 13:17:51 | jaypipes | alex_xu, avolkov: answered your queries on https://review.openstack.org/#/c/461574/9 | |
| 13:23:35 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: shared resources when finding providers https://review.openstack.org/461574 | |
| 13:23:48 | jaypipes | dansmith: addressed your comments ^ | |
| 13:25:19 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: test for agg association not sharing https://review.openstack.org/461901 | |
| 13:25:19 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: tests for non-shared with shared https://review.openstack.org/461899 | |
| 13:25:20 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: test non-shared out of inventory https://review.openstack.org/461900 | |
| 13:25:21 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: shared resources when finding providers https://review.openstack.org/461574 | |
| 13:27:45 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: test for agg association not sharing https://review.openstack.org/461901 | |
| 13:27:45 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: tests for non-shared with shared https://review.openstack.org/461899 | |
| 13:27:46 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: shared resources when finding providers https://review.openstack.org/461574 | |
| 13:27:46 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: test non-shared out of inventory https://review.openstack.org/461900 | |
| 13:29:01 | bauzas | cdent: question, how can we know if allocating an instance was wrong ? | |
| 13:29:36 | cdent | bauzas: what do you mean by wrong? | |
| 13:29:58 | bauzas | cdent: I need to know whether the allocation was accepted, ie. 204 | |
| 13:30:17 | bauzas | cdent: calling _put_allocations() returns a bool about that | |
| 13:30:41 | bauzas | cdent: so that means that if some allocation is not accepted by the scheduler, then _put_allocations would return False, right? | |
| 13:31:01 | cdent | yes | |
| 13:32:02 | bauzas | okay | |
| 13:32:25 | openstackgerrit | Jay Pipes proposed openstack/nova master: add cache which keeps DB and os_traits in sync https://review.openstack.org/462769 | |
| 13:33:14 | efried | dansmith (or whoever) - is there a concept of `nova-manage cell_v2 discover_hosts` failing? In a way that it would exit nonzero to the shell? | |
| 13:34:03 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455 | |
| 13:34:05 | dansmith | efried: https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L1443 | |
| 13:34:12 | dansmith | efried: only if an exception gets raised | |
| 13:34:27 | efried | dansmith - esberglu_ is seeing failures in our CI (host not mapped to any cell) that one would normally see if above was not run, but console log shows it running (and not failing) | |
| 13:34:33 | avolkov | jaypipes: thanks for explanation | |
| 13:34:38 | efried | dansmith Thanks, I'll look through that. | |
| 13:34:50 | dansmith | efried: running with --verbose and seeing it actually discover the host you expect? | |
| 13:35:09 | efried | dansmith Okay, will try. esberglu_ ^^ can you stuff that into the script? | |
| 13:35:27 | esberglu_ | efried: I'm running through it manually on a test instance right now | |
| 13:35:31 | esberglu_ | I will add verbose | |
| 13:36:13 | efried | esberglu_ Cool beans. Thought you said you couldn't reproduce when running manually, though. (dansmith FYI, esberglu_ suspected timing - running discover_hosts too soon after services were started) | |
| 13:36:46 | dansmith | efried: yep, definitely possible | |
| 13:38:16 | efried | dansmith Okay. Possible to patch such that it will fail if it doesn't discover anything? Possibly at the behest of a --strict flag? (Sorry if that's a naïf question; I don't have the background to understand whether that can really be considered a "failure" per se.) | |
| 13:38:46 | efried | (and other borrowed words from Latin languages) | |
| 13:38:51 | dansmith | efried: I would think that you should exit nonzero if it _did_ discover something, and then scripts can "run-until-success" | |
| 13:40:04 | efried | dansmith Sorry, making sure we're talking about the same thing: shell command exits zero on *success*, nonzero on *failure*, yes? So ^^ implies that discovering something is failure?? | |
| 13:40:34 | dansmith | well, it's also often used to mean "I did something out of the ordinary" or "I took action" | |
| 13:40:53 | dansmith | all you hosts should be discovered all the time, so if it found one that isn't, it's out of the ordinary | |
| 13:41:29 | dansmith | I mean you could argue that discovering a host is what you intended to do when you ran it, and so not discovering anything is the error, | |
| 13:41:38 | efried | dansmith Right, that's how it feels to me. | |
| 13:41:45 | dansmith | but I think the way people will use it will be "run until it reports success" | |
| 13:42:10 | efried | dansmith I can buy it, but if that's the case, I feel like it should be called out as such in the doc. | |
| 13:42:28 | efried | esberglu_ ^^ So as currently coded, sounds like you want to do something like: | |
| 13:42:44 | dansmith | it needs to be called out in either case, like the update_cell docstring | |
| 13:42:49 | efried | esberglu_ while ! nova-manage cell_v2 discover_hosts; do sleep 1; done | |
| 13:43:07 | dansmith | efried: no, not as currently coded.. it always returns zero unless something actually explodes | |
| 13:43:16 | efried | dansmith Oh, okay. | |
| 13:43:38 | dansmith | efried: but you can do that, document it, and backport it to ocata if you want :) | |
| 13:44:07 | efried | dansmith Roger that. esberglu_ ^^ may be a good way to get you into nova contribution ;-) | |
| 13:47:16 | efried | dansmith On first read of the update_cell doc, it sounds like the paradigm is "exit zero if it works, nonzero if something goes wrong" - so I would expect discover_hosts to be similar. Did I read it right? | |
| 13:47:22 | esberglu_ | dansmith: efried: Sure. I will take a look after I get this CI issue sorted out | |
| 13:47:36 | dansmith | efried: they're entirely different commands though | |
| 13:48:01 | dansmith | efried: it's not a failure to run discover_hosts and not find anything | |
| 13:48:11 | dansmith | it _is_ a failure to update_cell and not ... update the cell | |
| 13:48:49 | efried | dansmith A new user may have a hard time understanding that. I say "discover" and nothing is discovered - seems like a failure. | |
| 13:48:57 | efried | (Speaking as a new user myself ;-) | |
| 13:48:59 | dansmith | efried: right now people are running discover_hosts and always seeing zero exit, so which do you think will be less disruptive to those people | |
| 13:49:13 | dansmith | efried: but discover_hosts is something you can (and some people do) run in cron | |