Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-25
17:49:54 sean-k-mooney melwitt: so my preference would be have result be a type that you can just do "if result: #handel sucess else : # handel error"
17:50:58 melwitt sean-k-mooney: we also have "did not respond" i.e. timeout waiting for result
17:51:02 sean-k-mooney melwitt: to do that you would have to override __bool__ in the wrapper class to see if the value was an exception type or not
17:51:19 melwitt which could be an error, but then you have to check the type of the error
17:51:34 melwitt but I guess we have to do that anyway if we're differentiating
17:52:46 sean-k-mooney melwitt: ya. if you stuff the exeption into the value field you can just rerais it and cactch it polymorifclly assuming the timeout is a different exception type
17:53:13 melwitt yeah, could do that
17:53:49 sean-k-mooney melwitt: so basically its the same as what you suggted but your hiding the type checking in a dedicated class that does it for you instead of doing it in multiple places
17:55:34 sean-k-mooney melwitt: python3's concurrent futures basically wrap this up nicly for you too but they are python 3 only https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future
17:56:09 melwitt sean-k-mooney: thanks
17:59:57 sean-k-mooney melwitt: want me to mock up an example of using what i described so you can see how it would work. im not sure its the correct solution in this case but its what i would try personally.
18:05:09 melwitt sean-k-mooney: an example that would work for python2 also? I would be interested in looking at it if you mock it up
18:05:57 sean-k-mooney melwitt: yes i can make it work for python too. ill mock something up and push it with some unit tests showing its usage later tonight
18:06:17 sean-k-mooney *python 2
18:06:50 melwitt thanks
18:16:34 openstackgerrit Jack Ding proposed openstack/nova master: Handle missing marker during online data migration https://review.openstack.org/605164
18:17:11 jaypipes man I fucking hate the scheduler unit tests.
18:17:15 jaypipes what a pile of shit.
18:17:59 sean-k-mooney jaypipes: let me guess asserting behavior 3 levles deep then just the local function behvior?
18:19:39 sean-k-mooney anyone know where the devstack log is stored by default? ther eused to be an xstack log in /opt/stack/logs but that seams to not be a thing anymore
18:20:10 jaypipes sean-k-mooney: more the endless hierarchy of copy/pasted test case classes.
18:20:39 sean-k-mooney jaypipes: yeah OOP
18:22:11 sean-k-mooney jaypipes: did i mention im playing with creating a programming language. it "object orianted" current it does not allow inheritence but you can have objects :P
18:26:30 AJaeger mriedem: could you review the other stable backports of that ceph change as well, please?
18:26:47 mriedem yeah
18:28:22 AJaeger thanks
18:31:58 melwitt what is going on with the gate lately? changes that have been in the queue for 26 hours
18:33:12 AJaeger melwitt: high failure rate plus one of our clouds down, see clark's email from a week ago or so
18:33:49 melwitt found it, thank you
18:33:52 AJaeger melwitt: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134867.html
18:34:40 AJaeger melwitt: still applies regarding cloud down - clarkb is testing a fix right now
18:46:27 openstackgerrit Jonte Watford proposed openstack/nova master: This commit adds __str__ and __repr__ methods to objects InstanceNUMACell and NUMACell. These will generate more readable representations of the objects for use in logs. https://review.openstack.org/600269
18:48:57 mriedem AJaeger: waiting to see the renamed job run on ocata https://review.openstack.org/#/c/602023/
18:49:44 AJaeger mriedem: good catch - you won't see it. We miss the parent devstack job there. This needs different handling - I'll fix...
18:54:27 openstackgerrit Jonte Watford proposed openstack/nova master: This commit adds __str__ method to objects InstanceNUMACell and NUMACell. These will generate more readable representations of the objects for use in logs. https://review.openstack.org/600269
19:01:36 mriedem jaypipes: i've got an o.vo problem that maybe you can help solve,
19:01:58 mriedem i've got an Instance object from cell1, pulled fresh from the db so there are no fields marked as 'changed',
19:02:30 mriedem i want to clone that object and re-create it in cell2 which should mean just changing the context to point at cell2 db and delete the id field so Instance.create() won't puke on it,
19:03:01 mriedem the problem is, the cloned object doesn't have any changed fields marked, so Instance.create() doesn't actually save anything into the cell2 db for the instance for things like vm_state, task_state, etc
19:03:54 mriedem know of any way to dirty up the object so it looks new? I tried a obj_from_primitive(obj.obj_to_primitive()) dance but that doesn't work b/c it maintains the 'changes' list of dirty fields
19:04:30 mriedem i'm thinking i might just have to do something like, new_obj = objects.Instance(new_context, **instance.obj_to_primitive()['data'])
19:05:58 melwitt mriedem: I think the only precedent we have for that is the get_new_instance in build request https://github.com/openstack/nova/blob/master/nova/objects/build_request.py#L237
19:07:29 sean-k-mooney mriedem: can you do a deep copy and then instead update the cell and then instaead of resetting the fileds just mark them as dirty?
19:07:30 mriedem blech, ok i'll hack that up the same
19:08:07 melwitt there might be a better way to do it, just mentioning that as a data point
19:08:49 mriedem yeah i'll copy that,
19:08:55 mriedem as i've seen and from dansmith's comment in that code,
19:09:01 mriedem keeping the fields dirty would involve ovo internals
19:09:24 melwitt aye
19:09:32 mriedem like passing a dirty_white_boy=True kwarg to obj_from_primitive
19:19:14 jaypipes mriedem: yeah, it's blech.
19:20:38 mriedem i'm still waiting for someone to get my foreigner reference
19:24:24 jaypipes heh
19:24:29 melwitt sorry, I only know the major foreigner hits
19:26:02 mriedem hey it made it to the top 12 https://en.wikipedia.org/wiki/Dirty_White_Boy_(song)#Chart_performance
19:26:36 melwitt huh.
19:37:28 sean-k-mooney yeah cirros does not have sriov drivers for 1gb intel nics ...
19:38:07 mriedem ok i've got something hacked up for now
19:38:28 mriedem http://paste.openstack.org/show/730743/
19:39:41 sean-k-mooney mriedem: without messing with internal that looks resonably clean
19:40:17 sean-k-mooney mriedem: it would be nice to a "mark_dirty" function instead of setattr(new_obj, field, getattr(obj, field)) but that works
19:40:53 mriedem i'll post something to ovo that dan can look at while he's pooing in a cave
19:50:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Option "scheduler_default_filters" is deprecated. https://review.openstack.org/604148
19:51:35 imacdonn mriedem: is there an easy way to see what 'nova-manage db online_data_migrations' would do, without actually doing it ?
19:51:37 sean-k-mooney melwitt: im going to call it a night an grab a beer. am im going to start hacking on that exection wrapper class and ill push something up in an hour or so while i wait for dinner. ill add you as a reviewer when i submit the patch.
19:52:46 mriedem imacdonn: as in a dry run option?
19:52:49 mriedem no there isn't
19:53:02 mriedem jaypipes: sean-k-mooney: like this https://review.openstack.org/605199
19:53:19 melwitt sean-k-mooney: cool, thanks
19:53:32 imacdonn mriedem: yeah. ok. I think that would be useful. I tried hacking out the check for max-count being greater than zero, but it's not that simple, apparently
19:54:27 mriedem imacdonn: well, you'd have to plumb that down through all of the online data migration routines
19:54:31 mriedem to not actually commit any changes
19:54:34 mriedem so it's not trivial
19:54:49 imacdonn mriedem: also, this doesn't seem right. The counts in the table should be non-zero? Caveat: it's Queens, so if anything's been fixed since then .... http://paste.openstack.org/show/730819/
19:55:30 sean-k-mooney mriedem: is the condition on line 401 reversed? e.g. should it be if leave_dirty?
19:57:34 sean-k-mooney mriedem: i would have expected the changed filed to be the dirty fields personally but i have not really looked at how this works closely
19:58:15 mriedem no
19:58:46 mriedem if not False (True): set the same changed fields on the copy as were on the primitive
19:58:53 mriedem which defaults to no changed fields
19:59:02 openstackgerrit Jonte Watford proposed openstack/nova master: Add __str__ method to objects NUMACell instances https://review.openstack.org/600269
20:01:07 openstackgerrit Merged openstack/nova stable/rocky: Follow devstack-plugin-ceph job rename https://review.openstack.org/602018
20:01:07 sean-k-mooney mriedem: i have added myself as a review and ill step through it properlly tomorow.
20:01:27 mriedem imacdonn: well that table definitely looks wrong...
20:01:46 imacdonn mriedem: yeah. Trying to figure out how that could happen
20:02:05 mriedem my guess is you're dumping the last result set,
20:02:11 mriedem which is when there were no more things to migrate
20:02:18 mriedem so you get 0s at the end
20:02:48 imacdonn I'm just running the command :)
20:02:54 imacdonn but yeah
20:02:59 mriedem you said you hacked something
20:03:19 imacdonn Oh, I only hacked out the check that max-count has to be >0 .. but I'm not applying that here
20:03:22 mriedem however,
20:03:23 mriedem http://logs.openstack.org/87/604687/4/check/neutron-grenade/6c10d43/logs/grenade.sh.txt.gz
20:03:30 mriedem shows that the table output is also busted in our grenade run
20:03:41 mriedem http://logs.openstack.org/87/604687/4/check/neutron-grenade/6c10d43/logs/grenade.sh.txt.gz#_2018-09-25_09_44_39_645
20:03:56 mriedem well...
20:04:02 mriedem maybe not, if we just don't have anything to migrate
20:04:02 imacdonn I think you're right .. I think that each call to _run_migration clobbers the previous result, instead of adding to it
20:05:39 mriedem that populate_uuids migration was added in queens, and looking at a grenade run from queens, we should see bdms getting migrated to have a uuid, and i'm not seeing any results in the table for a grenade run on queens
20:05:40 mriedem http://logs.openstack.org/48/604448/1/check/neutron-grenade/19d8166/logs/grenade.sh.txt.gz

Earlier   Later