Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-22
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`
14:02:10 dansmith efried: I think a command of "is host $hostname mapped" that returns a boolean is likely to be useful for scripting deployments
14:02:19 dansmith list_cells shouldn't return hosts, IMHO
14:02:26 efried dansmith okay.
14:02:27 dansmith but a list-hosts-in-cell command is probably also useful
14:04:09 esberglu_ efried: dansmith: Just getting caught back up. Sounds like the two takeaways are that we want to add
14:04:26 esberglu_ - A --strict flag to the discover_hosts command (and backport to ocata)
14:04:51 esberglu_ - A new command to check if a host is mapped
14:05:07 esberglu_ - A new command to list hosts in a cell
14:05:21 esberglu_ (3 takeaways)
14:05:35 efried esberglu_ Probably not #3
14:06:10 openstackgerrit Jay Pipes proposed openstack/nova master: placement: test for agg association not sharing https://review.openstack.org/461901
14:06:11 openstackgerrit Jay Pipes proposed openstack/nova master: placement: test non-shared out of inventory https://review.openstack.org/461900
14:06:21 dansmith #3 seems useful to me too, but that's the order of importance, yeah
14:07:42 esberglu_ K I'm on the hook for that. I'll be back with questions I'm sure
14:32:20 openstackgerrit sahid proposed openstack/nova master: libvirt: update the logic to configure volume with scsi controller https://review.openstack.org/459741
14:32:21 openstackgerrit sahid proposed openstack/nova master: libvirt: update LibvirtConfigGuestDeviceAddress to provide XML https://review.openstack.org/459737
14:32:21 openstackgerrit sahid proposed openstack/nova master: libvirt: update logic to configure device for scsi controller https://review.openstack.org/459740
14:32:22 openstackgerrit sahid proposed openstack/nova master: libvirt: set full description of the controller used by disk https://review.openstack.org/459738
14:32:22 openstackgerrit sahid proposed openstack/nova master: libvirt: rearange how scsi controller is defined https://review.openstack.org/459739
14:37:16 mriedem https://review.openstack.org/#/c/430608/ worries me a bit - it's defining what "in progress" means for various types of migrations which is going to impact how the API works
14:37:32 mriedem i.e. post-copy is not considered in-progress,
14:37:43 mriedem and there is no 'evacuating' status while we're actually performing the evacuate
14:38:02 mriedem seems like this could be a mess to manage in the future, since we're exposing an internal state machine out of the api
14:39:57 openstackgerrit Dan Smith proposed openstack/nova master: De-complicate some of the instance delete path https://review.openstack.org/458636
14:39:58 openstackgerrit Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634
14:39:59 openstackgerrit Dan Smith proposed openstack/nova master: Fix live migration devstack hook for multicell environment https://review.openstack.org/458537
14:39:59 openstackgerrit Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635
14:40:00 openstackgerrit Dan Smith proposed openstack/nova master: Target cell on local delete https://review.openstack.org/464059
14:52:18 danpawlik mriedem: : Hi. Can you review https://review.openstack.org/#/c/459753/ when you have some free time? Thanks
14:55:07 mriedem cdent: alex_xu: wondering about your opinions on 400 vs 409 here https://review.openstack.org/#/c/459483/5/nova/api/openstack/compute/server_migrations.py@89
14:55:16 mriedem it might not matter since we're never very consistent on those
15:18:33 mriedem sfinucan: replied in https://review.openstack.org/#/c/464088/
15:18:40 mriedem sfinucan: i think we can assume the db name doesn't have / in it

Earlier   Later