Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-17
15:13:57 artom Had some scary legals emails about the Huawei embargo thing
15:14:05 aspiers artom: :-(
15:14:12 aspiers what a crappy situation
15:14:35 aspiers also I'm guessing pretty unprecedented and nonsensical in an open source context
15:14:59 jangutter I am so glad South Africa is no longer under sanctions.
15:16:11 mriedem artom: i've heard
15:16:22 mriedem realize that i already know all of your secrets before you tell me
15:16:42 artom If you knew all my secrets you'd be in an asylum
15:19:16 artom aspiers, it's definitely weird... though I suspect if there's on legal department that can make sense of it, it's RH's, given our open source history
15:19:21 artom *one legal
15:19:59 aspiers or SUSE's - a few months older than RH even ;-)
15:20:07 aspiers although we're no longer an American company
15:20:13 aspiers so maybe we don't need to care as much
15:20:48 aspiers I'm sure RH has a much more impressive army of lawyers than we do too
15:22:23 artom True, though being German (albeit with US... affiliates?) they may not be subjected to the same laws
15:22:39 aspiers We're not German
15:22:46 aspiers Owned by EQT which is Swedish
15:23:02 aspiers but we have companies in many countries around the world, just like RH
15:23:28 aspiers so yeah, there'll be a SUSE Inc. or whatever
15:23:44 aspiers and SUSE GmbH, SUSE UK Ltd. etc.
15:24:11 aspiers each of those subject to the whims of the respective country
15:24:12 openstackgerrit Merged openstack/python-novaclient master: Optimize limit option docs string description for novaclient https://review.opendev.org/643035
15:24:53 aspiers I wonder if it could result in situations where Huawei-related work could get taken off the hands of American members of a team and given to colleagues in other countries
15:24:58 artom aspiers, in our case even our non-US companies are subject to the embargo
15:25:09 aspiers interesting, why's that?
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

Earlier   Later