Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-13
16:45:48 mmedvede dims: do you think there are inherent problems with using github vs git.o.o?
16:46:00 melwitt mriedem: yeah, that's what I was thinking about
16:46:04 mriedem it might just mean, print a message saying you need to run map_cell_and_hosts or discover_hosts after you've added compute nodes
16:46:06 bauzas mriedem: I know a bit of puppet world and idempotence, and I think it's reasonable
16:46:42 bauzas I mean, it's a reasonable assertion that an idempotent script can only provide a portion of what it can modify on the first run
16:46:42 mmedvede dims: ok, I see your comment above now re our CI going down with github
16:46:43 dims mmedvede : just surprised. you may get a stronger reaction from infra folks if you tell them :)
16:46:52 dims mmedvede : right
16:46:52 owalsh mriedem: yea, I don't like it either, but if we do want to communicate a specific condition in this way then non-zero, but not 1
16:46:59 bauzas but eventually, after X runs, it would do all required
16:47:25 mriedem bauzas: melwitt: note that with the nova-status upgrade check command,
16:47:35 mriedem we don't consider it a failure if you don't have any computes yet https://github.com/openstack/nova/blob/3ec43d81c324d8229bbb4b5db301175886a049b6/nova/cmd/status.py#L168
16:47:39 mriedem but you have cell mappings and cell0
16:47:48 mriedem which is specifically for the fresh install case
16:47:58 melwitt mriedem: right, that's what I was trying to work backward from
16:49:21 melwitt mriedem: I like your idea about printing a message if simple_cell_setup finds no hosts, with a reminder what to do once you have compute hosts. the thing is the incomplete setup, things actually work fine for now because we have a bunch of fallbacks if no cell mappings, we run the old way
16:50:26 rfolco dims, stronger reaction means they disagree ?
16:50:59 dims rfolco : i think they would prefer direct git.openstack.org for sure
16:51:28 mriedem melwitt: hmm, the db schema migration will fail if you don't have cell mappings,
16:51:38 mriedem melwitt: but if you run that before adding flavors, then it's a noop
16:51:57 bauzas mriedem: melwitt: interesting, we return 0 in map_cell_and_hosts even if we have no hosts...
16:52:04 rfolco dims, ah ok. thanks for the ping.
16:52:10 mriedem so you could run the api_db sync, it passes b/c no flavors, then you run simple_cell_setup which only creates cell0, and then you register your computes - you won't have any cell mappings for those
16:52:17 mriedem bauzas: yeah i think that's part of the bug fix
16:52:20 mriedem as noted above
16:52:47 mriedem melwitt: i'm pretty sure we are dumping warnings in the logs if we don't find a cell mapping and fallback to the main db
16:52:53 bauzas mriedem: yeah, I will change that
16:53:08 melwitt yeah, I can't remember how that got decided. probably the argument of "error condition vs not"
16:53:24 mriedem melwitt: the automatic compute node / cell mapping registration would fix this...but it's just not something we've been serious about adding
16:54:08 mriedem thinking about gradually increasing levels of pain, which has been our MO,
16:54:12 melwitt mriedem: yeah. it's not straightforward how to do that because, how do you make assumptions about what cell to auto map new hosts to? usually that's deliberate decision on the part of the operator
16:54:28 mriedem we could do the fallback with a warning in ocata, then make that an error in pike
16:54:40 dtp afk a bit
16:54:47 mriedem melwitt: right you'd need to probably flag some cell mapping as the 'default' to auto-register with
16:55:19 mriedem so in ocata we have the fallback mechanism if we don't find a cell mapping,
16:55:34 melwitt yeah, that's what I had in mind. new stuff goes into some "staging cell" and then after that you have to re-map. though I don't even think we have a way to re-map
16:55:38 mriedem which buys us some time to consider an auto-registration in pike, or remove the fallback and make it an error
16:56:05 mriedem melwitt: we'd probably have to write a REST API for remapping, or nova-manage CLI
16:56:19 melwitt yeah, probably nova-manage
16:58:46 mriedem ok i've added those questions to https://wiki.openstack.org/wiki/Nova-Cells-v2#Open_Questions
16:58:55 melwitt mriedem: I'm wondering if maybe map_cell_and_hosts should stay as returning 0 (since it prints what the deal is, if it found nothing to map)
16:59:04 bauzas mriedem: melwitt: patch is wired, just a few mins for adapting tests
16:59:54 melwitt and later code warnings let you know that you need to do something, if no cell mappings are found while nova is running
17:00:12 mriedem melwitt: _map_cell_and_hosts treats that differently
17:00:18 mriedem if things are already done, it returns a uuid https://github.com/openstack/nova/blob/3ec43d81c324d8229bbb4b5db301175886a049b6/nova/cmd/manage.py#L1275
17:00:22 mriedem if there are no computes, it returns None
17:00:36 mriedem None is the error, the uuid is the non-error we're already done case
17:01:26 melwitt okay, yeah
17:01:31 bauzas mriedem: melwitt: is the proposed patch http://paste.openstack.org/show/594860/
17:02:05 melwitt I think we have had this debate before, is doing nothing really an error. I think we usually say it isn't
17:02:30 melwitt from the perspective of returning a non-zero
17:04:15 mriedem it probably depends on the command
17:08:18 mriedem sdague: melwitt: if you're not otherwise distracted, can you take a look at this https://review.openstack.org/#/c/398472/ - would be good to get that in and avoid more rebasing
17:09:33 mriedem bauzas: when you're done with this bug fix are you going to address my comments on the resource providers 'resources' query patch
17:09:34 mriedem ?
17:09:47 bauzas mriedem: I had an hard day
17:09:53 bauzas mriedem: but yeah it's in my pipe
17:09:59 mriedem heh, ok :)
17:10:33 mriedem jay might be able to make those updates too but he's not around right now
17:12:08 bauzas mriedem: no worries, today is not ended for me
17:12:26 dims mriedem : sdague : the py35 change for nova boot/attach/detach/delete working is all green - https://review.openstack.org/#/c/419476/
17:12:28 bauzas I'm not Jack Bauer but there 24 hours in a day
17:13:11 mriedem sean-k-mooney: if you're willing it'd be great to rebase this series https://review.openstack.org/#/c/410737/
17:13:22 mriedem the merge conflict is i think b/c of the os-vif unit test fix i made yesterday
17:14:02 mdbooth bauzas: Jack Bauer would say that if he was trying to maintain cover...
17:14:05 mdbooth Just saying
17:14:06 sean-k-mooney mriedem: sure if francesco is not around i have i can rebase them
17:14:19 mriedem sean-k-mooney: i don't know his irc nick,
17:14:25 mriedem or if he's even on irc but don't see him
17:15:02 mriedem frasantoro - nope
17:15:12 sean-k-mooney im just finishing up another commit but ill try and rebase this in the next hour or so if that works for you.
17:15:31 mriedem sounds good, i'll get to it eventually if you can't, it's fine
17:15:46 mriedem i'm going to head to lunch, bbiab
17:17:34 openstackgerrit Sylvain Bauza proposed openstack/nova: Accept simple_cell_setup to partially complete its tasks https://review.openstack.org/420079
17:17:56 bauzas melwitt: mriedem: ^
17:31:46 dims thanks sdague !
17:42:52 openstackgerrit John Garbutt proposed openstack/nova: WIP: Call preallocate_for_instance before scheduler https://review.openstack.org/413124
17:42:52 openstackgerrit John Garbutt proposed openstack/nova: WIP: Add processed_requests to allocate_for_instance https://review.openstack.org/420103
17:52:42 openstackgerrit Sarafraj Singh proposed openstack/nova: Adopts keystoneauth with glance client. https://review.openstack.org/412634
17:55:26 cfriesen any libvirt experts around? When nova calls self._domain.resume(), is that an async call or a sync call? i.e. when it returns has qemu actually transitioned to a "running" state, or does it just send a message but it could be delayed due to scheduling?
17:59:10 openstackgerrit Sarafraj Singh proposed openstack/nova: Adopts keystoneauth with glance client. https://review.openstack.org/412634
18:01:40 openstackgerrit Sarafraj Singh proposed openstack/nova: Adopts keystoneauth with glance client. https://review.openstack.org/412634
18:03:57 openstackgerrit John Garbutt proposed openstack/nova: WIP: Call preallocate_for_instance before scheduler https://review.openstack.org/413124
18:24:46 jroll mriedem1: I'm +1 on the ironic attach/detach/portgroups patches, ruby is out today but I expect she'll be happy with them too
18:24:59 jroll the soft power client patch needs another re-spin
18:25:13 jroll I think that's all I have to update you on...
18:25:47 jroll oh, the hashring thing we did last cycle, that's released in tooz now, do y'all have time for a patch to move to use tooz this cycle yet? (should be mostly ripping code out)
18:33:37 mriedem jroll: umm, maybe
18:34:14 mriedem jroll: there was also the inject nmi patch but i think that was waiting on some dependencies too
18:34:42 mriedem cfriesen: i usually default to think that anything libvirt/qemu does is async
18:34:45 jroll mriedem: yeah, that's not even done in ironic, I don't expect it this cycle
18:34:49 mriedem i think most things are done via an async job
18:35:01 mriedem cfriesen: kashyap or mdbooth or sahid are the people i'd ask
18:35:06 mriedem jroll: ok
18:36:38 jroll mriedem: I'll do the tooz thing now so you can see how simple it is. it passed tests with flying colors about a month ago with some weird depends-ons
18:37:09 mriedem ok, just got back from lunch and still sore from the cells v2 beating i took this morning
18:37:48 openstackgerrit Jim Rollenhagen proposed openstack/nova: Move to tooz hash ring implementation https://review.openstack.org/399022
18:37:48 jroll oh, easiest merge conflict ever
18:37:52 jroll there you are if curious
18:38:56 openstackgerrit Jim Rollenhagen proposed openstack/nova: Move to tooz hash ring implementation https://review.openstack.org/399022

Earlier   Later