| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-22 | |||
| 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? | |
| 13:54:34 | efried | Cause none of this was implemented in newton? | |
| 13:54:34 | dansmith | efried: aye | |
| 13:54:39 | efried | (or at least not required) | |
| 13:54:45 | dansmith | not required yeah | |
| 13:54:47 | efried | dig | |
| 13:55:11 | dansmith | efried: just MHO but we did similar things before to make the transition easier before people got there, so I think it's legit | |
| 13:55:36 | dansmith | that way esberglu_ gets the full gamut of nova dev interaction :) | |
| 13:56:00 | efried | Trial by fire | |
| 13:57:11 | efried | dansmith So `nova-manage cell_v2 list_cells [--verbose]` doesn't show which hosts are in which cells? | |
| 13:57:53 | dansmith | efried: I think it does, but it won't return pass/fail for a single host.. but you can use grep and get that I think | |
| 13:57:53 | efried | nope | |
| 13:58:03 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 13:58:09 | dansmith | oh wait, | |
| 13:58:14 | dansmith | not after my faster-er patch | |
| 13:58:15 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 13:58:18 | dansmith | but in ocata you can I think | |
| 13:58:31 | dansmith | in master now, it is able to efficiently determine which hosts are unmapped | |
| 13:58:37 | dansmith | in ocata it couldn't, which means it had to get them all | |
| 13:59:32 | efried | dansmith Would list_cells be an appropriate place to put the "include mapped hosts" behavior? Potentially via a new flag? | |
| 14:00:04 | mriedem | is it odd that migration.status goes from accepted -> pre-migrating -> done | failed; with no 'evacuating' or middle state? | |
| 14:00:09 | mriedem | for evacuate i mean | |
| 14:00:36 | efried | dansmith Versus a whole new command, like `nova-manage cell_v2 host_mapping` | |