Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-09
18:32:18 efried ganso: Oh, those are stein. I'm not stable, so I can't really help you :)
18:32:35 efried gmann: Okay, I think that's the plan.
18:32:46 ganso efried: oh, sorry... I'll look for the stable maintainers
18:32:48 gmann +1
18:33:01 efried gmann: Current bp is going to add sorting/filtering by the locked bool.
18:33:05 efried iiuc
18:33:16 efried but ignore locked_by entirely - not fix it or remove it.
18:34:29 mriedem ganso: https://review.openstack.org/#/admin/groups/540,members
18:34:38 mriedem ganso: but also, those can't merge yet anyway b/c we haven't GA'ed stien
18:34:38 gmann efried: you mean current spec will start ignoring 'locked_by' from sort/filter ?
18:34:40 mriedem *stein
18:35:04 ganso mriedem: oh right! release is friday, correct?
18:35:05 gmann i feel leave it as it is currently.
18:35:06 mriedem hence my -W on the bottom patch
18:35:11 mriedem ganso: tomorrow i think
18:35:17 efried gmann: No, sorry, I mean the current spec will do nothing to change locked_by in any way.
18:35:29 mriedem dansmith: grab a rake
18:35:41 gmann efried: +1
18:46:51 openstackgerrit Lee Yarwood proposed openstack/nova master: Block swap volume on volumes with >1 rw attachment https://review.openstack.org/572790
18:46:52 openstackgerrit Lee Yarwood proposed openstack/nova master: Keep attach_mode as top-level field in _translate_attachment_ref https://review.openstack.org/574413
18:47:34 lyarwood mriedem: ^ hope you don't mind, this came up downstream last week, finally getting back around to it now and noticed some whitespace.
19:34:44 tssurya mriedem, dansmith: thanks for reviewing https://review.openstack.org/#/c/636132/ , sorry didn't get time to respond, will go through it tomorrow.
19:35:12 dansmith tssurya: hopefully we can make this one every bit as painful as the locked_by one!
19:35:14 dansmith (not)
19:41:57 mriedem lyarwood: fine with me, but you'll have to convince mdbooth since i think it was held up on him, plus this tempest change https://review.openstack.org/#/c/573025/
19:44:11 lyarwood mriedem: ack thanks will do
19:44:50 mriedem lyarwood: btw i was told you own this now https://review.openstack.org/#/c/551349/
19:46:10 lyarwood mriedem: yeah, I've just not found my way back to it since the last PS
19:46:25 mriedem let your heart guide you young lee
19:47:05 lyarwood mriedem: I'll queue it up for the morning, thanks for the review!
20:24:18 mriedem so we agree we're not going to sort/filter on locked_reason right
20:24:19 mriedem ?
20:27:11 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Support adding the reason behind a server lock https://review.openstack.org/638629
20:28:51 gmann mriedem: right. filter/sort by 'locked' only
20:29:12 mriedem efried_afk: well, got one spec approved today
20:29:30 mriedem who has the champagne? is dansmith still alive?
20:31:00 dansmith heh
20:38:16 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969
20:38:37 gmann mriedem: updated the readonly info for OS_EXt prefix fields ^^. OS-DCF:diskConfig i propose to change in request also.
20:38:54 gmann checked all the extensions fields and listed the one with prefix
20:48:20 openstackgerrit Merged openstack/nova-specs master: Support adding the reason behind a server lock https://review.openstack.org/638629
21:27:38 efried mriedem: \o/ but a lot got done today.
21:27:58 efried and especially leading up to today, with people fleshing their specs.
22:37:20 mordred efried: heh libvirt gorp
22:38:31 openstackgerrit Dakshina Ilangovan proposed openstack/nova-specs master: Nova LLC allocation - RMD plugin for RDT CAT https://review.openstack.org/651233
23:31:40 alex_xu mriedem: hah, hope that is cold medicine :)
#openstack-nova - 2019-04-10
00:46:49 openstackgerrit Merged openstack/nova stable/rocky: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646686
01:51:44 openstackgerrit melanie witt proposed openstack/nova master: Use futurist.GreenThreadPoolExecutor in scatter_gather_cells https://review.openstack.org/650172
02:44:33 openstackgerrit Boxiang Zhu proposed openstack/nova master: Use the functional test test_parallel_evacuate_with_server_group https://review.openstack.org/649963
02:45:17 openstackgerrit Li Zhouzhou proposed openstack/nova stable/queens: SRIOV pci_numa_policy dosen't working when create instance with 'cpu_policy' and 'numa_nodes https://review.openstack.org/651429
06:15:09 kaisers efried: Thanks for looking. I'm busy with other stuff atm but will follow up on your feedback later on!
07:09:14 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove deprecated 'default_flavor' config option https://review.openstack.org/645476
07:47:34 openstackgerrit Adrian Chiris proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
08:00:13 sean-k-mooney alex_xu: which comment wast that?
08:00:49 sean-k-mooney i didnt get time to review as much specs yesterday as i would have liked but i assume one of the cpu frequencey specs?
08:02:09 sean-k-mooney alex_xu: ah i see you replied on https://review.openstack.org/#/c/649882/ ill take another look in an hour or so
08:09:49 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
08:27:21 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
08:44:21 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
08:58:07 alex_xu sean-k-mooney: thanks!
08:58:26 alex_xu sean-k-mooney: I mean all of them, they are good comments :)
09:02:16 alex_xu sean-k-mooney: I saw you like the extra spec defined in https://review.openstack.org/#/c/651024/5/specs/train/approved/rmd-plugin-energy-efficiency-core-p-states-control.rst@310, but I'm not quite understand, it will be great you have an example for it, if it is good, I'm happy to change also
09:02:29 alex_xu for now, I need to offline for catching my daughter
09:02:44 sean-k-mooney ok o/
09:02:51 alex_xu thanks!
09:03:02 sean-k-mooney and ya i like it more as its a finite set
09:03:18 sean-k-mooney using arbiarty traits makes me a little uneasy
09:03:26 alex_xu ah, i see now
09:03:38 sean-k-mooney it could be fine just need to get used to the idea
09:04:13 alex_xu but I don't want to assume there are only two priority(high and low), the user may have their own configuration, they can have some custom tratis
09:04:43 alex_xu anyway, I have to go, catch up you later
09:05:05 sean-k-mooney they may but that is an interoperablity headache between clouds. sure dont be late for dad taxi service :)
09:46:55 kashyap alex_xu: sfinucan: After some more thinking last night, I'm updating that `cpu_model_list` spec a bit more
09:47:03 kashyap Err, stephenfin ^ :-)
09:47:29 kashyap stephenfin: On the name, I'm responding on the change...but quickly here: I didn't even think of the "Hungarian Notation" until you mentioned :-0
09:47:35 kashyap But I see your point, though.
09:48:04 kashyap IMHO, it's just unambiguously clear to go with the _list; instead of playing with alises and such.
09:48:13 stephenfin kashyap: Yeah, I really don't think it's necessary. oslo.config is powerful enough to let us handle the migration issues, as I noted
09:48:33 kashyap I've seen far too many such subtle and confusing mistakes in config attributes in the past. :-(
09:48:45 stephenfin Perhaps, but you're going to have to use aliases anyway, assuming you want to remove the current value at some point in the future
09:49:00 sean-k-mooney kashyap: useing _list may be clear but it breaks convention
09:49:07 kashyap I see. It's not merely the technical. But I'm still not convinced from the human / operator "visual clarity"
09:49:24 kashyap sean-k-mooney: What convention? We should break "conventions" when it makes sense.
09:49:40 stephenfin I think that matters less than you think. People don't set nova.conf files, tools do
09:49:52 sean-k-mooney the conventions of we just use the plural form to denote lists in the config
09:49:59 stephenfin Be that TripleO, Kolla, or something else
09:50:24 kashyap Yeah, realize it as much. I want to wait a bit more to convince myself
09:50:41 sean-k-mooney kashyap: im not arguing _list is wronge im just saying i dont think its that important if its _list or plural
09:51:10 kashyap (I'm not convinced. I'll think a bit more and write on the review.) But there's more important bits in that spec to tackle, though
09:51:24 stephenfin sean-k-mooney: If I resize an instance, does that instance move host?
09:51:25 kashyap (The more I think about this topic, the more subtle questions I can think of...)
09:51:35 stephenfin s/does/can/
09:51:43 sean-k-mooney not in all cases but it is allowed too move
09:52:20 sean-k-mooney rebuilds are always to the same host but resize default to migration but you can enable resize to same host in the config in which case we dont add the current host to the ingroed host list
09:58:16 sean-k-mooney stephenfin: does that make sesnse ^
09:58:22 stephenfin sean-k-mooney: It sure does
11:00:24 yaawang bauzas: stephenfin Thanks for your review. I agree with your comments about not expose driver's feature to the REST api. So how about putting these into the flavor extra flags and image metadata? Use these properties to datermine whether to use 'auto converge' or 'post copy' during live migration.
11:22:54 trident Are there any specific reasons why block migration is not implemented with the LVM backend? Any specific issues with getting it to work or just that nobody has implemented support for it?
11:47:18 kashyap stephenfin: Idea: Is this any palatable: `acceptable_cpu_models`? (It closely captures the intended meaning _and_ we can avoid "Hungarian")
11:47:51 kashyap (I am wary of bike-shedding, while knowing that "naming is hard", so want to avoid mistakes when I can. :-))

Earlier   Later