Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-07
15:36:31 mriedem i.e. the API does some logic and shoves stuff in the request spec, which passes through conductor to the scheduler
15:36:47 mriedem i'd prefer if that was all more explicit between api->conductor-scheduler
15:37:07 mriedem because whenever i look at the conductor code i have to know exactly how the api code works
15:38:09 bauzas mriedem: when I wrote the original blueprint, there was a reason
15:38:45 bauzas mriedem: I necessarly needed to set the Spec fields by the API because the force or not force logic is there
15:39:22 bauzas mriedem: plus the fact that you can call again the conductor by the compute if you resize
15:39:48 bauzas mriedem: those reasons led me to set the fields there in the API
15:40:11 bauzas but I agree with the fact that is spaghetti code
15:42:06 mriedem i've tried to document the hell out of all of these areas that i've had to touch for live migration and evacuate to help clarify some of it
15:42:19 mriedem but we still need some detailed documentation in the request spec object itself per my ML email
15:42:40 mriedem plus the fact that we don't convert some things to primitive in the request spec
15:42:42 mriedem which seems like a bug
15:43:09 mriedem but, i don't really know enough about it or if it's something we should care about
15:43:25 mriedem i.e. if you only have to convert to a primitive for legacy stuff due to an old scheduler client, then we probably don't care
15:45:52 bauzas when you say primitives, you mean legacy dictionaries ?
15:46:17 bauzas not the primitived dictionary in terms of o.vo ?
15:46:55 bauzas honestly, the problem is that we still have lots of back-and-forths between those legacy dicts and the new object, which is errorprone
15:47:24 bauzas so, my goal is to reduce those by changing the scheduler helper methods to accept a spec object
15:51:20 mriedem the legacy dict
15:53:36 mriedem gibi: in https://review.openstack.org/#/c/417882/23/doc/notification_samples/instance-resize-error.json it looks weird in a few places where there are empty dicts or lists and there is a blank line in between
15:54:22 bauzas by reading the news, all my thoughts go to folks in Florida, Georgia and South Carolina. Hope jaypipes will be all good
15:54:49 jaypipes bauzas: it's a logistical nightmare :(
15:55:18 bauzas jaypipes: you're far from me, buddy so I can hardly help
15:55:29 jaypipes bauzas: heh, I know :) it's cool, dude.
15:55:35 bauzas jaypipes: but in case you need anything I can do, just lemme know
15:55:41 jaypipes bauzas: thx :)
15:56:12 bauzas jaypipes: you're temporarly relocating, as you said ?
15:57:38 jaypipes bauzas: yeah, though plans have changed... now looking to got to Asheville, NC for a night, drop the girls off with my parents and then catch flights out of ATL.
15:57:47 jaypipes bauzas: it's a clusterf**k
15:59:20 bauzas :(
16:17:10 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Remove 'vendordata_driver' opt https://review.openstack.org/397835
16:17:14 openstackgerrit John Garbutt proposed openstack/nova master: Enable test_iscsi_volume in live migration job https://review.openstack.org/459316
16:17:36 stephenfin mriedem: Per mikal's comment earlier, could you remove the -2 on this, please? https://review.openstack.org/397835
16:18:30 mriedem stephenfin: what was mikal's comment earlier?
16:19:05 stephenfin mikal: Do you think this change could be restored now? https://review.openstack.org/#/c/397835/
16:19:17 stephenfin <mikal> stephenfin: yeah, I think we could take another pass at that now
16:19:53 stephenfin mriedem: I assume that means the vendordata v2 stuff is done? idk for sure, personally
16:20:20 mriedem mikal made improvements in ocata
16:20:33 mriedem https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/vendordata-reboot-ocata.html
16:21:52 stephenfin Ultimately though, does that mean configurability of vendordata driver is no longer required?
16:24:01 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: DNM: Unformatted file https://review.openstack.org/501798
16:24:01 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: DNM! Make "reproposals" more obvious to readers https://review.openstack.org/501797
16:24:24 efried mriedem Bitter. So bitter.
16:27:01 mriedem gdi i can't find the vendordata v2 stuff in the docs nova
16:27:02 mriedem *now
16:27:32 mriedem that should be in admin, or user, or reference, or something
16:30:41 sdague it's in user/
16:31:03 sdague but, I'm trying to figure out if it's linked in anywhere
16:31:55 sdague https://docs.openstack.org/nova/latest/#maintenance
16:32:02 sdague Exposing custom metadata to compute instances: How and when you might want to extend the basic metadata exposed to compute instances (either via metadata server or config drive) for your specific purposes.
16:32:41 mriedem ok, not really maintenance
16:32:45 mriedem but at least it's somewhere
16:32:59 sdague well... putting things in buckets is hard
16:33:05 mriedem i know,
16:33:08 mriedem i'm just really gd grumpy today
16:35:42 sdague need some salad with marshmellows in it
16:38:16 sean-k-mooney mriedem: oh speaking of maintenance if you were wondering why the intel nfv ci has not been posting for a few days its because it did "maintenance"
16:39:22 sean-k-mooney mriedem: they completely blocked ssh connection out of the datacenter and we are arguing with them to whitelist review.openstack.org and our logserver...
16:43:53 cdent edleafe, jaypipes : do either of you have opinions on the two different body formats described in https://review.openstack.org/#/c/499259/ ? dansmith and I both have a bit of a preference for the dict-ish style.
16:45:18 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: Run test_iscsi_volume with new style volume attachments https://review.openstack.org/501805
16:45:18 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: test new style volume attach with live migration https://review.openstack.org/481290
16:46:58 dansmith mriedem: so we're good on that whole stack now yeah? and you'll propose backports when they land?
16:47:07 mriedem dansmith: yup
16:47:42 mriedem bauzas: were you ok with this now? https://review.openstack.org/#/c/499399/
16:47:45 mriedem i updated the reno
16:51:54 efried stephenfin Re neutron VIF NUMA affinity - jaypipes had some general ideas about how to model this generically using placement aggregates.
16:52:37 stephenfin efried: Yeah, I figured placement would come into it on the nova side. rn I'm more curious about how we get this information from neutron though
16:52:49 efried stephenfin It's noted in the 'generic device management' etherpad we're teeing up for the PTG: https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management
16:53:34 efried stephenfin See around line 69 if you want to add some notes for specific stuff you're thinking for this case.
16:53:41 jaypipes cdent: will try to review in a bit. currently still trying to arrange hotels and flight changes... :(
16:54:06 mriedem efried: does https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management supersede the block of stuff in https://etherpad.openstack.org/p/nova-ptg-queens starting at L74?
16:54:08 efried stephenfin And the mess starting at line 77 talks about how nova & neutron are going to play together.
16:54:08 cdent jaypipes: good luck with all that jaypipes
16:54:12 efried mriedem Yes
16:54:12 mriedem because if so that would be nice to replace
16:54:15 mriedem as the main etherpad is getting huge
16:54:24 efried mriedem I've been working on moving content over.
16:54:34 mriedem ok, please remove from the main page when yo'ure done
16:54:37 mriedem i'm doing the same with cells
16:54:55 efried mriedem It's actually all represented - I didn't delete from the original because then we lose all the attributions. Do we care about that?
16:55:17 stephenfin efried: Oh, now that's interesting
16:55:26 stephenfin Fancy replying to that mail with those notes?
16:55:29 cburgess Yeah jaypipes are you the wife and bugs GTFOing I hope?
16:55:29 mriedem i don't really care about the colors, this is why i tell people to put their name/nick next to an item
16:55:33 stephenfin (for anyone note on #openstack-nova)
16:55:45 cburgess pugs.. not bugs
16:55:51 cburgess You can take the bugs with you too I suppose.
16:58:54 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: Run test_iscsi_volume with new style volume attachments https://review.openstack.org/501805
16:59:17 jaypipes cburgess: yeah, we're heading up to ATL by car on Saturday early morning (like 4am)
16:59:42 jaypipes cburgess: all pugs aboard the pug train.
16:59:58 cburgess jaypipes Oh good, stay safe. You coming to denver or going to be riding it in out in ATL?
17:00:18 openstackgerrit Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
17:00:35 jaypipes cburgess: I got delta to put me on the monday flight instead of the sunday flight so I'll be in Denver Monday evening through Friday night
17:00:39 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: DNM! Make "reproposals" more obvious to readers https://review.openstack.org/501797
17:00:39 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: DNM: Unformatted file https://review.openstack.org/501798
17:01:07 cburgess jaypipes Cool, well hope the drive is smooth and your house gets through it.
17:01:14 sean-k-mooney stephenfin: are you +1 or -3 on the idea of using the sriov nic agent to create the vf resouce providers and apply traits such as physnets?
17:01:32 sean-k-mooney stephenfin: im assuming most people will not have an in between on that idea
17:01:51 jaypipes cburgess: hotel with the pugs for Sat and Sun nights, Julie flies to Italy from ATL on Sunday afternoon, parents driving down from Maine to meet me in ATL on Sunday night to take the girls and then I fly out Monday to Denver...
17:01:59 jaypipes cburgess: total logistical nightmare.

Earlier   Later