| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-22 | |||
| 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 | |
| 13:49:18 | dansmith | it's idempotent | |
| 13:49:33 | dansmith | so, would you like an email from cron every time it runs and doesn't find anything, or every time it does? :) | |
| 13:49:41 | bauzas | dansmith: mriedem: jaypipes: cdent: edleafe: I'll need to take some PTOs by this week, so I won't be around for Wed-Frid | |
| 13:49:43 | efried | dansmith Or a --strict flag | |
| 13:50:00 | jaypipes | bauzas: k, thanks for the heads up. | |
| 13:50:02 | dansmith | efried: sure, or that | |
| 13:50:14 | bauzas | dansmith: mriedem: jaypipes: cdent: edleafe: the series is in a good pace, you can review it | |
| 13:50:19 | jaypipes | bauzas: can you give edleafe permission to take over any patches you have in progress please? | |
| 13:50:36 | dansmith | jaypipes: +1 | |
| 13:50:37 | jaypipes | bauzas: I want to keep progress going. | |
| 13:50:42 | bauzas | as I said earlier, I'm fine with anyone working on my changes if we're not duplicating work | |
| 13:50:50 | jaypipes | bauzas: cool, thank you sir. | |
| 13:51:24 | bauzas | anyway, I'm still around for 24h | |
| 13:51:29 | dansmith | efried: --strict means we keep existing behavior without that being passed to avoid breaking anyone current right? | |
| 13:51:57 | dansmith | that's probably the best, in which case I'm good with not finding anything is an "error" | |
| 13:52:24 | efried | dansmith Right. Adding --strict would mean, "any result that isn't 'I discovered a host' is a failure." | |
| 13:52:36 | dansmith | yep | |
| 13:53:33 | efried | dansmith For current impl, is there a command I can use to ask whether this host has been discovered (registered with a cell)? | |
| 13:54:03 | dansmith | efried: no, such a command would be welcome too I think | |
| 13:54:12 | dansmith | efried: also I think you can backport the --strict patch | |
| 13:54:15 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 13:54:19 | efried | dansmith To ocata? | |