Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-25
13:11:07 kashyap stephenfin: Err, sorry, was assuming context. This one: https://review.openstack.org/#/c/577385/
13:11:51 kashyap In relation to the comment you made, which I addressed. But there are lot of other configs that don't use the multi-line string approach.
13:11:57 stephenfin No one is bulk converting them, no. However, changing them as we go (as you've done there) seems like a viable option to me
13:12:10 kashyap Yeah, I think that's the best too.
13:12:49 stephenfin I'm pretty sure mriedem, supreme hater of "noise" patches, would prefer that approach too :P
13:13:05 kashyap Yeah, I wasn't vonluteering to produce that noise either :-)
13:13:07 mriedem ``noise``
13:13:25 mriedem lyarwood: comments on those patches
13:13:28 mriedem for the evac thing
13:13:31 lyarwood mriedem: thanks
13:14:04 sahid melwitt, mriedem, do you think we could consider https://review.openstack.org/#/c/553072/ for stable?
13:17:53 mriedem sahid: i wouldn't block it, even though it's enabling something that wasn't on stable for certain types of vifs, but i guess that could be argued as a bug
13:18:09 mriedem might need a release note
13:33:51 openstackgerrit Merged openstack/nova stable/queens: Be graceful about vif plugging in early ironic driver startup https://review.openstack.org/576948
14:39:39 openstackgerrit Merged openstack/nova stable/pike: Ensure resource class cache when listing usages https://review.openstack.org/574327
15:05:25 bauzas dansmith: mriedem: cdent: efried: I have a question about allocations for a resize/cold migration
15:05:47 bauzas dansmith: mriedem: cdent: efried: for the moment, we don't pass the allocations to the driver when calling resize
15:05:58 bauzas but we do it for rebuild
15:06:46 bauzas so, for the moment, we have a problem with vGPUs like said in https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#caveats
15:07:36 mriedem so pass allocations to the driver on resize
15:07:51 efried yeah, that seems like it was probably just an oversight.
15:08:01 bauzas efried: so, my question is : can I call self.reportclient.get_allocations_for_consumer() for getting all the allocations, even the migration one ?
15:08:09 dansmith I assume anything like this will eventually need allocations yeah
15:08:28 mriedem bauzas: the allocations for the source host moved to the migration object
15:08:31 efried bauzas: As long as you know the migration UUID, yeah.
15:08:34 mriedem you want the allocations for the dest host, which are on the instance
15:09:15 mriedem are you properly freeing vgpus from the source host when confirm_resize is called?
15:09:19 bauzas mriedem: so, tbc, when calling self.reportclient.get_allocations_for_consumer() in the compute service for resize_instance(), it would give me the migration UUID allocation ?
15:09:35 mriedem bauzas: it depends on what you need and where you call it
15:09:42 bauzas I see
15:09:50 mriedem if you're on the dest host and need the vgpus for some kind of claim on the dest host, you want to use the instance uuid
15:10:00 bauzas if I'm asking for the migration UUID, it would give me the related alloc
15:10:12 mriedem https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/migration-allocations.html
15:10:22 mriedem if you're asking for the migration uuid, you get the source host allocations
15:10:22 bauzas if I'm asking for the instance UUID, it's giving me the instance alloc
15:10:39 mriedem during a move, the source host allocations are on the migration record and the dest host allocations are on the instance
15:10:53 bauzas until we call finish_resize?
15:11:05 mriedem finish_resize != confirm_resize
15:11:10 bauzas oops, yeah
15:11:15 bauzas confirm_resize I meant
15:11:26 mriedem this does the allocation swap https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L27
15:11:26 bauzas okay, thanks, I was a bit confused
15:11:42 bauzas okay, thanks for the link, I think I understand now
15:11:58 mriedem cdent: efried: now that i'm looking at this, fyi on the fixme here re shared providers https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L56
15:12:16 mriedem so while we might support shared providers*, we've got a pretty big asterisk most likely
15:13:34 cdent in our copious free time (whooo dawg) we should try to fix that
15:13:42 mriedem dansmith: so i'm seeing this weird issue where i've got a versioned object with a DictOfStringsField, and the dict has some strings and boolean value
15:13:46 mriedem *'ed fields in it,
15:14:05 mriedem at some point along the way, the values in the dict are converted to strings, but i'm having a hard time figuring out where that is, but it looks like it must be coming from the coerce() somewhere
15:14:20 mriedem DictOfStringsField means the *values* in the dict are strings right?
15:14:31 dansmith mriedem: if you have a dict of strings, it will str() everything you try to set in there
15:14:43 dansmith right at the point of setting it on the object, but definitely during/after serialization
15:14:59 mriedem i was playing with that locally and wasn't seeing it at the point of setting the field
15:15:18 mriedem {'port_filter': True, 'datapath_type': 'system', 'ovs_hybrid_plug': True}
15:15:18 mriedem >>> obj.foo
15:15:18 mriedem >>> obj = MyObj(foo=vif_details)
15:15:23 dansmith well,
15:15:33 mriedem ...
15:15:33 mriedem ... }
15:15:33 mriedem ... 'foo': fields.DictOfStringsField(),
15:15:33 mriedem ... fields = {
15:15:33 mriedem ... VERSION = '1.0'
15:15:33 mriedem >>> class MyObj(base.NovaObject):
15:15:33 mriedem with
15:15:34 dansmith if you set the dict on the field and the manipulate the dict, then it won't do it immediately
15:16:02 dansmith okay, well, hmm,
15:16:18 dansmith maybe even when you set the dict it won't because it's complex, but I thought it would
15:16:24 dansmith definitely during serialization though I think
15:18:09 mriedem False
15:18:09 mriedem >>> obj.obj_attr_is_set('foo')
15:18:09 mriedem hmm
15:18:16 mriedem something weird in my test
15:25:26 openstackgerrit Stephen Finucane proposed openstack/nova master: Replace support matrix ext with common library https://review.openstack.org/481304
15:30:14 dansmith mriedem: did you @register_if(False) it?
15:30:20 dansmith otherwise you don't get the magic fieldage
15:30:24 mriedem nope
15:32:43 mriedem http://paste.openstack.org/show/724236/
15:32:49 mriedem maybe this just doesn't work without some stubs
15:32:52 mriedem or fixture setup
15:33:05 mriedem anyway, i realize i can't use DictOfStringsField
15:33:20 mriedem because vif_details can have a shitload of random key/value pairs of several types
15:33:54 dansmith that's odd
15:34:02 dansmith if you serialize it does it show up in the result?
15:34:37 mriedem no because it says the field isn't set
15:34:46 dansmith you tried?
15:35:02 mriedem {'nova_object.name': 'MyObj', 'nova_object.version': '1.0', 'nova_object.data': {}, 'nova_object.namespace': 'nova'}
15:35:02 mriedem >>> obj.obj_to_primitive()
15:35:26 dansmith man, that's odd
15:36:43 dansmith is it any different if you don't pass it to __init__ ?
15:36:56 dansmith like o=MyObj(); o.vif_details =
15:37:02 mriedem nope
15:37:17 dansmith I just don't even
15:41:45 mriedem hmm, we don't have any generic DictField where the values aren't coerced?
15:42:07 mriedem crap i guess you can't
15:42:17 mriedem Dict is a CompoundFieldType which takes some kind of element
15:45:15 mriedem and this is why BlockDeviceMapping.connection_info is a StringField...
15:49:37 openstackgerrit Chris Dent proposed openstack/nova stable/ocata: Ensure resource class cache when listing usages https://review.openstack.org/574279
15:50:38 dansmith because it's full of random we don't control at the rpc layer yeah
15:51:41 openstackgerrit Surya Seetharaman proposed openstack/nova master: Make nova list and migration-list ignore down cells https://review.openstack.org/575734
15:52:08 mriedem right...this is why i'm stressing over this https://review.openstack.org/#/c/515423/28/nova/objects/migrate_data.py@41

Earlier   Later