| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-27 | |||
| 13:07:20 | leakypipes | gibi: sorry about that! | |
| 13:08:08 | gibi | leakypipes: no problem | |
| 13:08:30 | leakypipes | gibi: although... | |
| 13:08:41 | leakypipes | gibi: based on the commit message | |
| 13:09:12 | leakypipes | gibi: looks like this was intentional to make the calling interfaces consistent | |
| 13:09:20 | leakypipes | gibi: from the commit message: | |
| 13:09:20 | leakypipes | In following patches, I change similar method on List objects like UsageList.get_all_by_resource_provider_uuid() and AllocationList.get_all_by_resource_provider_uuid() to match this new pattern of get_all_by_resource_provider() and passing in a ResourceProvider object. | |
| 13:09:49 | leakypipes | gibi: those "following patches" were re-ordered and are actually already merged. | |
| 13:10:35 | gibi | leakypipes: that removes some of my confusion :) anyhow if there is pattern and it is intentional then I'm OK with it | |
| 13:10:43 | leakypipes | gibi: so, long story short, I did it for consistency with the other calls | |
| 13:11:18 | gibi | leakypipes: make sense now, thanks for the explanation | |
| 13:25:57 | belmoreira | mriedem, dansmith I continue to test how to migrate from newton to ocata with cellsV1 | |
| 13:26:15 | belmoreira | If I have multiple nova_api(s) DBs/placements I will need to merge the allocation tables when moving to pike and cellsV2 | |
| 13:26:30 | belmoreira | This is not easy to achieve because "allocations" table uses the "resource_provider_id" instead "resource_provider_uuid" | |
| 13:26:36 | jmccarthy | Question about using libvirt + xen on xen compute, anyone familiar with how to get changes to 'stick' when virsh editing the xml ? I'm trying to add another serial device to file, for console logging for example: http://paste.openstack.org/show/624831/ | |
| 13:26:42 | belmoreira | There is any way to recreate the "allocations" table from scratch when I'm in pike? | |
| 13:26:58 | jmccarthy | (I have what is on the right, but I think I need what is on the left) | |
| 13:27:43 | mriedem | belmoreira: would likely have to write a tool to migrate the entries out of the separate placement/api db's into the global one when you upgrade | |
| 13:27:53 | mriedem | we mentioned this as one of the trade offs the other day of doing placement per cell for now | |
| 13:28:37 | dansmith | what mriedem said | |
| 13:28:51 | dansmith | belmoreira: the use of integer ids is for performance there | |
| 13:30:27 | mriedem | bauwser: what is your -1 for specifically on this? https://review.openstack.org/#/c/515530/ | |
| 13:31:37 | bauwser | mriedem: on a meeting | |
| 13:34:58 | fried_rice | mriedem superdan Can we please move the ksa adapter series along a little bit? It's been stagnating. Here's one that involves placement https://review.openstack.org/#/c/492247/ -- sdague was +2 6 weeks ago and no actual changes since. | |
| 13:37:05 | sdague | fried_rice: it has a gerrit cannot merge on it atm | |
| 13:37:21 | fried_rice | sdague Aaargh, missed that. | |
| 13:37:33 | fried_rice | rebasing... | |
| 13:37:47 | superdan | also, I'm not really the best person to look at that | |
| 13:37:52 | superdan | probably mriedem and sdague though | |
| 13:38:26 | mriedem | fried_rice: you're just doing all of these separately right? | |
| 13:38:38 | mriedem | for some reason i thought they were all lined up behind the glance one, which looked scary | |
| 13:38:39 | fried_rice | mriedem Yes | |
| 13:38:49 | fried_rice | mriedem Oh, some of them are lined up behind the glance one. | |
| 13:38:53 | fried_rice | But this one isn't. | |
| 13:41:08 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/pike: Updated from global requirements https://review.openstack.org/493146 | |
| 13:41:39 | sdague | realized that after going from Ubuntu Unity -> Gnome 3 in 17.10, I lost my mechanism of knowing people had pinged me on irc. Think I got a solution for that today. Which hopefully means noticing when mriedem pokes at me | |
| 13:43:24 | belmoreira | mriedem, dansmith in newton when placement is enabled the resource_providers/allocations tables are populated. This doesn't happen for pike. Could this be achieved somehow? would be better than having a tool to merge the dbs | |
| 13:44:26 | mriedem | belmoreira: once all computes are upgraded to pike, the compute resource tracker stops reporting allocations in the update_available_resource periodic task | |
| 13:44:28 | mriedem | on purpose, | |
| 13:44:43 | mriedem | because in pike the scheduler creates allocations during create and move operations like migrate, | |
| 13:44:52 | mriedem | and the ocata computes would overwrite the allocations created by the pike scheduler | |
| 13:46:17 | superdan | what mriedem said again :) | |
| 13:47:11 | superdan | belmoreira: I think we should probably be on the hook to help with said merging tool because you won't be the only one that needs it | |
| 13:49:14 | openstackgerrit | Eric Fried proposed openstack/nova master: Use ksa adapter for placement conf & requests https://review.openstack.org/492247 | |
| 13:49:18 | fried_rice | sdague mriedem ^ | |
| 13:49:19 | mriedem | superdan: is there any specific reason that nova.objects.base.obj_to_primitive doesn't convert datetimes to primitives? | |
| 13:49:39 | superdan | mriedem: um | |
| 13:49:46 | belmoreira | mriedem if in ocata the resource tracker still reports the allocations, means that in my upgrade procedure I move to the global placement just before upgrade to pike. In that case I would not need to merge the dbs. | |
| 13:51:08 | mriedem | belmoreira: so you're going to update nova.conf on all of the computes to point at global placement, take down the control plane and wait for the periodic task to do the inventory and allocation population? | |
| 13:51:19 | mriedem | s/control plane/api | |
| 13:51:56 | mriedem | belmoreira: to be clear, the resource tracker will continue to update allocations in placement as long as there is at least 1 <pike compute | |
| 13:52:02 | superdan | oh _that_ obj_to_primitive | |
| 13:52:11 | mriedem | it's just once all computes are >= pike we stop doing that | |
| 13:52:21 | mriedem | superdan: yeah i expected that to turn the entire object and it's fields into primitives | |
| 13:52:39 | superdan | mriedem: that is really obj_to_dict() for doing unholy things.. it doesn't serialize an object | |
| 13:52:50 | mriedem | ok - was trying to figure out why we needed this https://review.openstack.org/#/c/515539/1/nova/scheduler/utils.py@a83 | |
| 13:52:57 | mriedem | when we had already converted objects to primitives above | |
| 13:53:01 | mriedem | guess it's not what i thought it was | |
| 13:53:12 | mriedem | like the bears in that cardinals game in the late 90s | |
| 13:53:20 | mriedem | with the dennis green post-game conference | |
| 13:53:23 | mriedem | leakypipes: ^ | |
| 13:53:25 | superdan | because someone wants a dict that looks like the object, probably for compat | |
| 13:53:56 | superdan | I would confirm, but a83 is not a line number | |
| 13:54:06 | mriedem | it's the left side of the diff | |
| 13:54:38 | belmoreira | mriedem yes, and then upgrade control plane/compute nodes to pike, and do the cellsV2 mappings. All of this in downtime of course. maybe it will be more error prone and easier than the DB merging | |
| 13:54:59 | mriedem | belmoreira: "less" error prone? | |
| 13:55:18 | superdan | oh sure enough | |
| 13:55:30 | mriedem | ok i'll just return the to_primitive call with a note | |
| 13:55:38 | belmoreira | s/more/less :) | |
| 13:56:02 | leakypipes | mriedem: not sure why the jsonutils call is there :( | |
| 13:56:41 | superdan | belmoreira: the merging should be easy I would think.. tbh that seems less concerning that running ocata computes for a period of time to build new placement data, but it's your call.. I assume you'll test it | |
| 13:56:47 | mriedem | leakypipes: i meant the football reference! | |
| 13:56:58 | mriedem | i need at least one football person in this channel | |
| 13:57:00 | mriedem | clarkb: | |
| 13:57:08 | leakypipes | mriedem: sorry, you lost me at hello on that one. | |
| 13:57:11 | superdan | mriedem: I'm still a big confused, because that's jsonutils, not obj_to_primitive | |
| 13:57:45 | mriedem | superdan: i removed the jsonutils.to_primitive becaues it's calling that on a request_spec dict, which i thought had already-serialized items in it, | |
| 13:57:55 | mriedem | because of the obj_to_primitive calls that happen above for the instance and flavor | |
| 13:58:00 | mriedem | so i thought it was a redundant call and removed it | |
| 13:58:06 | mriedem | leakypipes: https://www.youtube.com/watch?v=SWmQbk5h86w | |
| 13:58:20 | superdan | mriedem: oh I see.. dear god | |
| 13:58:32 | superdan | mriedem: those are dictified instance and flavor not a serialized instance | |
| 13:58:40 | mriedem | let'em off the hook jay | |
| 13:59:07 | leakypipes | mriedem: :) ok, gotcha now. | |
| 13:59:29 | superdan | I think what we've learned here is that football references have no place in a nerd hangout | |
| 13:59:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup build_request_spec https://review.openstack.org/515539 | |
| 14:01:15 | leakypipes | superdan: a lesson learned. it's a game of inches. sometimes you just need to go for it on fourth and ten. | |
| 14:01:24 | belmoreira | superdan if the data it's correctly recreated I would prefer to let the resource tracker do it. At the end should be faster than all the work required for the DB merging. Yes, I will test and let you know. Thanks | |
| 14:03:33 | mriedem | leakypipes: pretty risky unless you're in the red zone under the 2 minute warning and behind by over 3 | |
| 14:03:40 | mriedem | then you have no choise | |
| 14:03:41 | mriedem | *choice | |
| 14:04:23 | leakypipes | mriedem: right. though that's just a hail-mary pass to superdan at that point. | |
| 14:05:31 | mriedem | belmoreira: ok - the key thing being that you leave one compute at ocata until all of the other pike computes have reported their information | |
| 14:06:04 | mriedem | belmoreira: and you'd need some tooling to verify that is done, like querying placement for all active instances to make sure they show up with allocations | |
| 14:08:41 | belmoreira | mriedem ok. thanks | |
| 14:09:04 | bauwser | mriedem: https://review.openstack.org/#/c/515530/2/nova/conductor/manager.py@831 are you sure we can't have a rebuild where host=None ? I thought it was | |
| 14:09:18 | mriedem | bauwser: not for "rebuild" | |
| 14:09:27 | bauwser | mmmm | |
| 14:09:38 | bauwser | okay, then nevermind my -1, I'll changeit | |
| 14:09:49 | mriedem | bauwser: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2948 | |