Earlier  
Posted Nick Remark
#openstack-nova - 2019-06-20
19:14:06 sean-k-mooney1 and keep it all in one file but i think that is going to get annoying in the medium to long term
19:14:25 dansmith when it gets annoying we can split it up
19:15:00 sean-k-mooney1 well it was already annying me a littel :) but not enought to fight this battel to much
19:16:40 sean-k-mooney1 efried: im going to finish writing the 3 transform (as function not fucntors) and then ill start working on the dirver chagnes to report the tratis and move the filters to the end of the patch series
19:18:07 sean-k-mooney1 i might do the extraction fo the common helper code as a singel patch too and then build on that
19:18:25 sean-k-mooney1 that sound ok with people?
19:19:11 dansmith sean-k-mooney1: the three transforms need only be a single function..hopefully that's what you're planning right?
19:19:46 sean-k-mooney1 i was going to have one function for each to make the testing simplere but i can compess them
19:20:13 dansmith that is way (way) overkill, IMHO and just serves to get us to "annoying" sooner for no benefit :)
19:20:19 sean-k-mooney1 i would prefer to just add another fucntion to the dict everytime we add a new image metadata trait we support
19:20:38 dansmith but they're identical in behavior right?
19:21:03 sean-k-mooney1 i think i can generalise it actully
19:21:24 sean-k-mooney1 the main different is the field they match on and the prefix for the trait
19:21:36 dansmith I don't understand how it's not already generalized, but.. okay
19:21:38 sean-k-mooney1 that was on my todo list for the next versions anyway
19:23:58 sean-k-mooney1 which fucntio were you refering to by the way i plan to have only one filter fucntion transform_image_metadata but ideally i would also have one transfrom function that is paramaterised on teh traits prefix to use and the image metadata value to check
19:24:36 dansmith all you need is one function that inside it has a list of the properties to traitify
19:24:42 sean-k-mooney1 my StorageTrasform object is currently only parmaterised on the key to check but i wanted to refactor to also thake the prefix
19:25:11 sean-k-mooney1 ya ill make it simpelr in the next version
19:33:12 openstackgerrit Eric Fried proposed openstack/nova master: Inline trace_request_filter https://review.opendev.org/666663
19:33:15 efried dansmith, sean-k-mooney1: ^
19:33:35 dansmith damn, three away from double devil
19:33:57 efried I should go claim those next few numbers...
19:35:17 sean-k-mooney1 efried: i like that we will actully be using the return value for something outside of the tests
19:35:37 efried sean-k-mooney1: I didn't change anything from what was there before...
19:35:41 sean-k-mooney1 well i guess it was used in teh decorator before
19:35:45 efried yeah
19:36:19 sean-k-mooney1 im updating the docs string in my patch with the input paramaters so ill add a return parmaater to call that out too
19:36:27 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Claim https://review.opendev.org/666666
19:36:32 efried booya
19:36:39 efried now I just need to find a use for it
19:37:12 sean-k-mooney1 efried: with great power comes epic trolling :P
19:37:17 efried I can't wait
19:37:42 mriedem ooo
19:38:02 mriedem i can almost smell the goats blood
19:38:07 efried I'll be taking offers. Bitcoin and souls only.
19:39:49 mriedem i'd offer up taylor swift's soul so i don't have to hear that me-e-e-e-e song anymore
19:40:19 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Claim https://review.opendev.org/666666
19:43:48 efried kashyap: tbc, the spec in jroll's thread is for a *physical* tpm passthrough, so he doesn't have to wait for the "not-on-disk" feature of *virtual* tpm to become available.
19:46:31 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: WIP: Add host and hypervisor_hostname to create servers https://review.opendev.org/647671
19:53:11 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: WIP: Add host and hypervisor_hostname to create servers https://review.opendev.org/647671
19:57:45 lbragstad could add some black sabbath links to your docs
20:04:16 Nick_A why would admin password be stored in config drive meta_data.json but not shown in either meta_data.json or password when curling metadata from the guest?
20:39:45 openstackgerrit Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420
20:39:45 openstackgerrit Adam Spiers proposed openstack/nova master: Use fake flavor instead of empty dict in test https://review.opendev.org/662555
20:39:46 openstackgerrit Adam Spiers proposed openstack/nova master: Pass extra_specs to flavor in vif tests https://review.opendev.org/662556
20:39:46 openstackgerrit Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334
20:39:47 openstackgerrit Adam Spiers proposed openstack/nova master: Add and to AMD SEV guest configs https://review.opendev.org/636318
20:39:47 openstackgerrit Adam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required https://review.opendev.org/644565
20:39:48 openstackgerrit Adam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption https://review.opendev.org/666616
20:51:26 aspiers efried: first pass at series restructuring done
20:51:41 aspiers I'm sure you'll find things you still don't like :)
20:51:43 efried aspiers: cool. Sorry to be a PITA about this
20:51:48 aspiers np
20:52:07 efried it's the 'master switch' that's the most important thing.
20:52:36 aspiers I may not entirely disagree with your commit boundary preferences, but I agree 100% with the master switch thing, and 1000% with a pedantic approach which achieves high quality results ;-)
20:52:44 aspiers s/disagree/agree/
20:53:06 aspiers OK, that's enough (actually too much) work for today
20:53:14 aspiers 10pm and still haven't eaten
20:53:30 efried there must be a magic triangle of pedantry/quality/productivity
20:53:32 aspiers haha
20:53:44 aspiers screw productivity, it's all about pedantry/quality ;-)
20:54:02 aspiers BTW tomorrow may be my last day working on SEV for ~3 weeks since next week is SUSE hackweek, and then I'm off to the USA for 2 weeks holiday
20:54:13 efried ight.
20:54:24 aspiers I think Boris is back around now, so *maybe* he can help progress things while I'm gone
20:54:34 efried aspiers: In your absence, if small things come up, permission to address them without you?
20:54:39 aspiers sure!
20:54:59 efried so like you might (*might*) come back to find this merged
20:55:03 aspiers haha
20:55:15 aspiers well that would be a lovely welcome back, but I'm not expecting it
20:55:18 efried yes, laughter appropriate
20:55:43 aspiers BTW it's looking like I'm being more officially allocated to upstream work from now on
20:55:55 aspiers so this is very good news (for me at least, maybe not for you)
20:56:42 efried nice
20:56:47 efried it is good news for me
20:56:51 aspiers :)
20:56:55 efried been getting kinda breezy around here
20:57:00 aspiers more excuses to be a pedant ;-p
20:58:00 aspiers would be great if I got time to hack on that requested_resources stuff, for example
20:58:16 aspiers at the moment I'm slightly feeling the heat on the SEV stuff, as we have some internal deadlines
20:58:47 aspiers not for forcing stuff down upstream's throat, but for reaching something that is functionally near complete downstream
21:00:00 aspiers OK, dinner time. Hopefully zuul CI won't shit all over my latest patchsets :)
21:00:04 aspiers Cya tomorrow o/
21:00:47 mriedem having a meeting today?
21:01:00 efried oh, crap, I am completely unprepared.
21:32:42 efried hmph, probably no meeting next week due to idempotence day
21:34:27 efried week after next, rather
21:35:53 mriedem i read that as impotence
21:35:59 mriedem which is not something i celebrate in my house
21:36:11 mriedem and on that note, i'm out of here, o/
23:30:44 aspiers efried: you can abandon https://review.opendev.org/#/c/662557/13 too
#openstack-nova - 2019-06-21
00:42:51 openstackgerrit Dustin Cowles proposed openstack/nova-specs master: WIP: Spec: Use OpenStack SDK in Nova https://review.opendev.org/662881
02:25:29 alex_xu ls
02:25:31 alex_xu oops
02:26:49 alex_xu sean-k-mooney: if we want to put the vpmem on the numa node rp, then it looks like we still need the reshape API, so the upgrade won't be easy with separated rp for vpmem now. But I can't get explict reason we should put the vpmem on numa node rp, or the child rp of numa node rp.
02:27:59 alex_xu if we prefer to the vpmem as the child rp of numa node rp, then we can go to that way, and separate the rp for now
02:33:09 sean-k-mooney ya im not sure what the preference is
02:34:08 sean-k-mooney i really dont mind too much either way but i just tought it might be simpler in the long run if we started with them seperate
02:34:24 sean-k-mooney but its not a point im really going to rathole on
02:35:06 yonglihe mriedem: HI.

Earlier   Later