Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-17
15:25:13 artom IANAL
15:25:18 aspiers because the parent company is US? or some other reason
15:25:26 artom I guess
15:25:44 aspiers if so, SUSE wouldn't have the same issue
15:25:47 artom But yeah, we got a pretty strongly worded email that we essentially need to stop all dealings with Huawei, all over the world
15:25:59 aspiers crazy stuff
15:26:03 artom Apparently open source upstream communities are exempt from that, tho
15:26:08 artom Which is why mriedem is still my friend
15:26:13 aspiers hah
15:26:44 artom Oh man, you saw your chance and you went for it XD
15:26:54 aspiers ;P
15:37:16 aspiers kashyap: remind me, will your secure boot code care about <features> at all?
16:04:27 sean-k-mooney artom: that is tecnically a gray area
16:04:39 sean-k-mooney but most multintionall play it safe
16:05:54 sean-k-mooney efried: im going to finish earlish today. i have libvirt domcapabilies review on my todo for today is there anything else you want me to look at before monday
16:06:26 efried sean-k-mooney: I'm sure nothing is urgent, thanks for asking.
16:07:03 kashyap aspiers: The code-that-doesn't-exist-yet will care about it
16:07:11 sean-k-mooney cool ya im going to drop off irc soon which is why i asked
16:07:13 kashyap aspiers: I need to be AFK: catch up on Monday. Sorry
16:07:28 kashyap Have a good weekend, folks (in CEST)
16:07:33 aspiers kashyap: cya
16:07:41 aspiers sean-k-mooney: I'm just about to push a new patchset
16:07:54 aspiers in response to reviews from efried and stephenfin
16:08:19 aspiers efried: and one of the comments is "please can we discuss in IRC" ;-)
16:08:30 sean-k-mooney cool ill finish updating the downstream but then ill look at it then
16:08:42 sean-k-mooney *bug
16:09:05 efried aspiers: I'm here, discuss away.
16:09:21 aspiers efried: I don't want to repeat the long essay I've drafted in Gerrit ;)
16:09:30 aspiers efried: give me a few mins to finish the response
16:09:49 efried ack
16:12:01 mriedem gibi_off: i'm guessing we're not going to be able to backport the fix for https://review.opendev.org/#/c/512623/ without dropping the functional test as well because of all the underlying refactor to make the functional test work?
16:29:29 stephenfin mriedem: You think a patch to exclude the 'user_data' field for each instance logged in this log sounds reasonable? https://opendev.org/openstack/nova/src/commit/ed5b7c7fc311c2af8c8be09044bb2723141f6f0d/nova/scheduler/host_manager.py#L180
16:30:12 sean-k-mooney stephenfin: we woudl have to modify the __repr__ function in the ovo to not incude that right
16:30:13 stephenfin I'm looking at a log where the user has bulk created some instances and it's just pages and pages of base64 (?) data
16:30:32 stephenfin I guess? I know we do some filtering of objects on security grounds
16:30:41 stephenfin I was hoping to reuse some of that, if that's possible
16:31:11 sean-k-mooney ah then ya it could be simple so
16:32:31 sean-k-mooney well looks like you have the instace info as a dict so you would have to make a copy and just remove the user_data section from teh copy or replace it with a message saying it was remvoed
16:33:01 stephenfin Or that <?> marker that gets inserted by...something
16:33:08 stephenfin o.vo normally, I guess
16:33:10 sean-k-mooney yes that thing
16:33:27 sean-k-mooney e.g. so you can tell there was user data but not log it
16:35:23 mriedem stephenfin: you're looking at an old log then,
16:35:29 mriedem because that was fixed to only log instance uuids
16:35:56 mriedem https://opendev.org/openstack/nova/commit/4fd7c93726eff4cc0b010741ea1772cf19c314fc
16:36:05 mriedem https://review.opendev.org/#/q/I0eda1c58a7eb54121230c880818b4b1d0fdf4893
16:36:14 mriedem take that back to pike and ocata if you want
16:36:32 stephenfin I'm going to do just that. Thanks, mriedem
16:36:45 mriedem np
16:36:59 openstackgerrit Stephen Finucane proposed openstack/nova stable/pike: Do not dump all instances in the scheduler https://review.opendev.org/659832
16:37:07 sean-k-mooney oh the list grabs the keys that are the uuids neat
16:37:20 openstackgerrit Stephen Finucane proposed openstack/nova stable/ocata: Do not dump all instances in the scheduler https://review.opendev.org/659833
16:37:37 mriedem it's a dict, the uuids are the keys
16:37:48 sean-k-mooney yep
16:38:27 sean-k-mooney so going from inst_dict to list(inst_dict) when form full dict content to just keys whic is cool
16:39:01 sean-k-mooney or we could have dont inst_dict.keys() to be explicit but same effect
16:39:52 stephenfin sean-k-mooney: Python be cool like that
16:40:03 sean-k-mooney yes and no
16:40:21 stephenfin list(dict) has the advantage that you'll always get a list back
16:40:31 sean-k-mooney i know why python iterate over the keys not the items but it always trips me on things like that
16:40:33 stephenfin whereas with dict.keys(), you'll get an iterator on Python3
16:40:48 sean-k-mooney also true
16:40:52 openstackgerrit Adam Spiers proposed openstack/nova master: Add infrastructure for invoking libvirt's getDomainCapabilities API https://review.opendev.org/655268
16:40:53 stephenfin and I don't know how oslo.log handles that
16:41:21 sean-k-mooney i just would have expected list(dict) to be the same as list(dict.itmes()) but i also know why that is not the case
16:41:34 aspiers efried, sean-k-mooney: new patchset 4 and response to patchset 3 ^^^
16:42:02 efried The tox failure is weird, it's claiming it can't find deps, but they're being set in [testenv]
16:42:02 efried stephenfin: would you mind taking a quick look at this? https://review.opendev.org/#/c/659682/
16:42:22 stephenfin looking
16:43:03 efried stephenfin: This is a throwaway patch, so if it's fixable by adding explicit deps lines back in, that's fine.
16:43:30 stephenfin efried: They're being set in 'testenv', not 'testenv:functional'
16:43:43 efried no inheritance there?
16:43:51 efried okay
16:43:52 stephenfin Nope. tox isn't that clever
16:44:01 stephenfin Thankfully, tbh. It's already too clever
16:44:09 efried so just copy them into those envs
16:44:58 efried also would have thought having used envdir would be enough
16:45:05 efried but apparently something is *requiring* deps?
16:45:45 openstackgerrit Eric Fried proposed openstack/nova stable/stein: Skip _exclude_nested_providers() if not nested https://review.opendev.org/659206
16:45:45 openstackgerrit Eric Fried proposed openstack/nova stable/stein: DNM: Revert "Use external placement in functional tests" https://review.opendev.org/659682
16:45:55 efried thanks for the look stephenfin
16:58:47 efried aspiers: thanks for the updates. Convince me that LibvirtConfigDomainCapsFeature needs to exist *ever*.
16:59:13 aspiers efried: just saw your comment on the follow-up change about that
16:59:27 aspiers efried: think I see where you're coming from now, maybe
16:59:42 aspiers so your point is that a base class isn't needed here
16:59:58 aspiers even though we expect there to be other feature classes in the future
17:00:16 aspiers or at least, have no reason to believe that there definitely won't be
17:00:20 aspiers right?
17:00:27 efried Right, because the only thing you're doing with that base class is converting a positional 'name' arg into the 'root_name' kwarg.
17:00:40 aspiers Yeah, that's a fair comment
17:00:41 efried which the subclasses can do just as easily.
17:01:34 aspiers but couldn't the same argument apply to LibvirtConfigGuestDeviceAddress?
17:01:50 aspiers I was trying to follow the precedent which already seemed to exist in config.py
17:03:20 aspiers Anyway I'm not religious about the need for that base class
17:03:22 efried Looking... but I tend to be in the camp of "follow precedent thoughtfully"
17:03:37 aspiers We could always reintroduce a base class later if need be
17:03:43 aspiers I'm in the same camp for sure :)
17:03:59 efried no, **DeviceAddress does some actual things in its overrides.
17:04:43 aspiers I don't see any method in the DeviceAddress base class which adds any value
17:04:56 aspiers the subclass overrides do add value, naturally

Earlier   Later