Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-03
15:27:17 sfinucan We're supposed to use it for any official OpenStack projects now
15:27:24 sean-k-mooney but is it a theme for sphinx that is maintined by the docs team for consitnecy across all offical docs?
15:27:32 sean-k-mooney ok cool
15:28:19 mriedem sean-k-mooney: i don't actually know what the use case is,
15:28:28 mriedem but nested RPs might be an option, it did come up too for BM
15:28:37 mriedem but not for multi-node chassis,
15:28:50 mriedem more for modeling NICs and Disks
15:29:02 mriedem and putting traits on those like type and capabilities
15:29:35 sean-k-mooney mriedem: i think blade servers are a good candiated for nested resouce providers as anti afinity at the chassis level may be needed to ha reasons
15:31:33 mriedem yes that was one example that came up too
15:31:55 mriedem making sure you're not in the same rack as the other servers in the same group
15:32:51 sean-k-mooney mriedem: that could be modeled with aggregates too but i guess it just depends on what you are trying to achive.
15:33:07 mriedem we got talking about the distance stuff from the boston session which then goes down the road of do we standarize the distance enums? or do we leave that up to ops (which wouldn't be interoperable)? or do you define it at an SLA level, but is your SLA guaranteed within the same rack, row or DC?
15:34:57 sean-k-mooney mriedem: ceph stiks a resonably good blance there. they provide standard values in the crush map for osd,host,rack... but you can just change the vaule if you want too.
15:36:25 sean-k-mooney for example if you want to add a lay for chassis in between host and rack you can by editing the crushmap, honestly i dont know whay the best aproch would be but have a predifed set would be good for interop
15:42:12 mdbooth sfinucan: Here's a fun patch if you've got time: https://review.openstack.org/#/c/462521/ . It has 2 dependencies which are stacked above it.
15:43:19 mdbooth The idea is to automatically kick off a revert if it fails on the destination. It's a bit tricky basically because of instance state, migration state, and quotas.
15:44:06 mdbooth It's obviously a user-friendly feature, but it's actually intended as a workaround for a bug we can't easily fix right now due to our datamodel.
15:45:41 mdbooth Bug details are in the bug link, but basically if your resize fails on the destination node, your instance is using a deleted glance image, and you don't revert within 24 hours, it'll delete the only remaining copy of your image. At this point your instance is unrecoverable.
15:46:53 mdbooth Ideally we would have the image cache not delete the image in this case, but our datamodel means it's not possible to identify an instance which is awaiting confirmation on the destination.
15:47:51 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081
15:49:15 AJaeger mriedem, or any cores around?
15:49:34 AJaeger Could you please abandon this change: https://review.openstack.org/#/c/479657/ - it will never build and is wrong
15:49:38 AJaeger Hangs currently in zuul...
15:50:21 mriedem AJaeger: i don't see the abandon button
15:50:33 AJaeger ok, then I'll ask infra-root...
15:51:38 fungi that's a fun one
15:51:40 fungi looking now
15:52:21 AJaeger fungi, you're everywhere ;) Ignore my ping on #openstack-infra then :-) - and thanks
15:55:39 fungi okay, abandoned
15:56:04 AJaeger thanks
16:00:29 sfinucan mdbooth: Ooh, that's a tricky one
16:00:33 sfinucan Thanks for the context
16:04:08 mriedem melwitt: do you know if james is also serving VMs in his cloud or just baremetal?
16:06:13 bauzas mriedem: AFAIK, mel is on patriotic PTO today
16:06:44 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: DO NOT MERGE: debug failed test https://review.openstack.org/479818
16:08:05 jaypipes bauzas: responded.
16:08:10 mriedem bauzas: ok
16:08:18 jaypipes bauzas: there's no hurry on the n-r-p series, though.
16:08:28 jaypipes bauzas: allocation candidates is the more important one at this point.
16:08:32 bauzas jaypipes: I know, but I think your change is fine by me
16:08:35 bauzas jaypipes: sure
16:08:42 mriedem bauzas: can you go over this one? https://review.openstack.org/#/c/476631/15
16:08:55 mriedem is dan out today too?
16:09:02 mriedem i.e. is today a red hat holiday?
16:09:10 bauzas mriedem: dan too
16:09:16 bauzas mriedem: dunno
16:09:26 mriedem most people make it a long weekend
16:09:30 bauzas mriedem: pssst, I'm not an US folk :p
16:09:34 mriedem really?
16:10:23 bauzas even if we have elephants having trumps, any of them are our president :p
16:10:39 bauzas anyway, looking at your change
16:11:36 mriedem our child care provider is closed today so i'm hosting a play date and working
16:12:11 bauzas heh
16:15:13 openstackgerrit Gábor Antal proposed openstack/nova master: Add json style checking for sample notifications https://review.openstack.org/443677
16:31:47 sfinucan mdbooth: IMA I'm pretty confused by https://review.openstack.org/#/c/479802/
16:32:48 mdbooth sfinucan: What specifically?
16:33:10 sfinucan I left comments in the review, but tl;dr why's the scope change necessary?
16:33:36 sfinucan The only functional change I can see is that you removed the status check
16:34:05 mdbooth sfinucan: Actually in that one specifically the benefit is marginal
16:35:02 mdbooth sfinucan: The change is that everything after the instance is 'done' is outside the scope of the context manager
16:35:14 mdbooth Although you could argue that quotas should be in...
16:35:25 mdbooth Yeah, that one could probably reasonably go
16:36:00 mriedem mgagne: let me know if you have any questions about the instance action thing i'm talking about in https://review.openstack.org/#/c/454322/
16:36:02 mdbooth However, resize_instance is where it's at
16:36:39 mdbooth sfinucan: The issue in resize_instance is that you've cast the control flow to another host, but after that's happened you've still got this rogue context manager which might yet futz with your state
16:36:55 mdbooth There are no circumstances where you want that to happen
16:37:25 sfinucan mdbooth: wait, are you still referring to that patch or the next one in the series?
16:37:34 mdbooth sfinucan: The only you just posted
16:37:37 mdbooth errors_out_migration
16:38:04 mdbooth And that's directly relevant to the following patch, and why it's a dep
16:38:21 sfinucan ah, gotcha
16:38:26 sfinucan so 'finish_revert_resize' is the marginal change
16:38:37 sfinucan but 'resize_instance' is not
16:38:45 mdbooth Yeah, I could potentially ditch that bit of the diff
16:39:03 sfinucan yeah, you might drop that or at least split it. Just lets me reason about it a little easier
16:39:50 mdbooth The important one is resize_instance, because it does a cast
16:40:04 mdbooth So allowing the context to continue is a race
16:40:51 sfinucan mdbooth: You're referring to the call to finish_resize, yes?
16:40:58 mdbooth sfinucan: Yes
16:41:31 sfinucan OK, that clarifies things. Thanks for the explanation
16:41:52 sfinucan If you can split those out/drop the less necessary diffs, I'm good to sign off on that
16:43:43 mdbooth sfinucan: Thanks for looking at that.
16:43:49 sfinucan no problem at al
16:43:53 sfinucan *all
16:43:56 sfinucan *atal atal
16:44:17 mdbooth sfinucan: I've just quickly replied to 1 comment, btw. The scope change is actually related, even if it's not immediately obvious why.
16:44:55 openstackgerrit Merged openstack/nova master: pci: add uuid field to PciDevice object https://review.openstack.org/469147
17:10:02 claudiub mriedem: hello. i have a question. so there is a patch that basically sanitizes the instance object in the InstanceMetadata ( https://review.openstack.org/#/c/478991/3/nova/api/metadata/base.py ), which will get rid of the instance's context, which will make unset attributes no longer loadable. Do we have an alternative solution to this, rather than touching the lazy-loading attributes?
17:10:19 claudiub IMO, that can be very error-prone.
17:15:43 mriedem claudiub: i wasn't aware of that change, but i remember that we hit some issues with metadata api with multiple cells so fail to lazy-load correctly anyway; the commit message says this isn't the long-term strategic solution,
17:16:01 mriedem so i think long-term we want to whitelist what we store and cache
17:16:32 mriedem because we've had other bugs where we can't cache the instance object using things like memcache because it uses pickle and things in there don't pickle correctly, like the sqlalchemy db connection stored in the context, as noted in the commit message
17:16:50 openstack Launchpad bug 1694666 in OpenStack Compute (nova) "metadata service PicklingError: Can't pickle <class 'sqlalchemy.orm.session.Session'> when using memcached" [Medium,Fix released] - Assigned to Dan Smith (danms)
17:16:50 mriedem yeah that's what the bug was, i remember this bug https://bugs.launchpad.net/nova/+bug/1694666
17:17:15 claudiub well, can't the db connection be recreated after the pickle?
17:18:26 openstackgerrit Claudiu Belu proposed openstack/nova master: Hyper-V: fix live migration with CSVs https://review.openstack.org/380448
17:18:31 mriedem claudiub: maybe, probably depends on what that's needed for
17:18:52 mriedem claudiub: i'm assuming you guys have extra fields on the instance object for hyperv and you need to lazy-load stuff for the metadata api?
17:19:45 claudiub yeah, we need the device_metadata field when we create the instance config drive, but that's not really a niche field. it's a basic field needed for the config drive

Earlier   Later