Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-22
14:44:05 dansmith I have a huge difficulty distinguishing the colors, even to assign unattributed text to someone that said something elsewhere
14:44:10 sean-k-mooney but do you think we should be using the mailing list for eveything else
14:44:11 gmann i think ML is better than etherpad discussion for pre-ptg.
14:44:34 dansmith agree that gerrit is the place for anything that is a spec. for non-spec, mailing list for sure
14:44:48 gibi that was my default plan ^^
14:44:49 dansmith etherpad also doesn't tell you what things you've read and what things are new
14:44:49 gmann and where discussion going heavy then mark that for PTG discussion instead of overloading ML
14:44:56 sean-k-mooney gmann: i really hated the pre-ptg ml threads we have done in the past
14:45:08 dansmith gibi: ++
14:45:19 sean-k-mooney but if that is what we are going to do i guess ill have to live with it
14:45:32 gibi sean-k-mooney: I hated that too but maybe it was not because of the ML itself but because of the amount of information I needed to process
14:45:40 sean-k-mooney can i just ask that we do not complete any topic only in the mailing list
14:46:06 gmann sean-k-mooney: i think we tried to conclude the things on ML which got too much. I think we can burn lot of light weight topic discussion there
14:46:10 dansmith how many people that hate divergent ML threads are using a mailer that doesn't actually show threads hierarchically like gmail?
14:46:11 sean-k-mooney gibi: for me its the format not the amount of info
14:46:24 gmann and if any topic is going back and forth then say 'let's discuss in ptg'
14:46:41 gibi gmann: ^^ +1
14:46:42 sean-k-mooney dansmith: i use revesr chronolgical order
14:46:48 sean-k-mooney dansmith: not threads
14:46:53 sean-k-mooney dansmith: but that is not my issue
14:46:54 dansmith mmhmm :)
14:47:36 sean-k-mooney dansmith: my issue is that i often feel like people dont see or respond to comment i make on some thread and there is no way to bring that point back into one fo the other divergent threads
14:47:49 dansmith probably because they're using gmail
14:47:56 sean-k-mooney that mainly hapens when people cut out part of the email
14:48:00 dansmith because gmail is the worst thing ever
14:48:22 dansmith non-trimming emails considered harmful
14:48:23 sean-k-mooney well i use evolution locally so i can enable thread view i jsut dont but ya that could be part of it
14:48:52 sean-k-mooney dansmith: i think there are pros can cons to trimming
14:49:18 sean-k-mooney trimming creats divergent tread if there are multipe open topics that dont reconverge
14:49:35 sean-k-mooney but it allows you to focus on that topic
14:49:57 dansmith non-trimming means people take a sub-thread and redirect it to something that was actually a different sub-thread by grabbing something someone said days ago
14:50:19 sean-k-mooney a sorry
14:50:33 sean-k-mooney i tought you ment replying with just a snippit fo the full email
14:52:14 sean-k-mooney dansmith: gibi if you have recommenation of Netiquette for how to conduct a discussion on the mailing list or tools that help that would be good to share
14:52:46 dansmith agree that gibi should try to set some ground rules and police with a big stick
14:53:10 sean-k-mooney im aware of the normal process for the mailing list but if feel that is not quite adequet for design dicussions
14:53:29 gibi I have no stick but I will try
14:55:38 gibi :)
14:59:18 elod lyarwood: thx for the review!
14:59:22 elod gibi: https://review.opendev.org/#/c/721883
14:59:33 gibi elod: ack
15:02:37 gibi elod, lyarwood: thanks! I'm +1
15:03:17 elod \o/
15:59:16 gmann nova-next failure for multi network fix is merged now, feel free to recheck if failing on your patch - https://review.opendev.org/#/c/721767/2
16:14:42 openstackgerrit Andreas Jaeger proposed openstack/nova master: DNM: Testing tempest https://review.opendev.org/722060
16:15:53 kashyap lyarwood: Thanks for taking time to give feedback! I answered your questions on the change. (The interesting LM bits are at the end. Hope that makes sense)
16:16:45 openstackgerrit Andreas Jaeger proposed openstack/nova stable/rocky: DNM: Testing tempest https://review.opendev.org/722063
16:41:50 bauzas cores, the prelude section is up for reviews https://review.opendev.org/#/c/721548/
16:41:57 bauzas reminder, we have to merge it before we cut RC1
16:47:18 openstackgerrit melanie witt proposed openstack/nova stable/stein: Add config option for neutron client retries https://review.opendev.org/722077
17:03:27 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP block_device: Rework refresh_connection_info https://review.opendev.org/720769
17:27:54 gmann gibi: stephenfin its ready with gate result too - https://review.opendev.org/#/c/720129/12
17:44:08 melwitt gmann: I think you have a small bug here?
17:44:09 melwitt https://review.opendev.org/#/c/720129/12/doc/source/configuration/policy-concepts.rst@204
17:45:24 gmann melwitt: ah, thanks. fixing
17:57:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
17:57:20 gmann melwitt: updated ^^
18:00:13 melwitt gmann: was there discussion around why this is in the "features" section rather than the "upgrade" section? https://review.opendev.org/#/c/720129/13/releasenotes/notes/bp-policy-defaults-refresh-b8e6e2d6b1a7bc21.yaml@2
18:02:21 gmann melwitt: not yet. I put it in feature as this is disabled via flags to actually not breaking upgrade. if we enable scope or remove deprecated old rules then we can add that in upgrade section. is that correct way to think of upgrade section ?
18:02:52 melwitt gmann: yeah ... this case is not so straightforward I guess. dansmith thoughts? ^
18:04:11 dansmith I don't really think that it's appropriate to call it a feature. With the exception of someone sitting around hoping we'll make our policy more granular, most people will see it as an upgrade-related piece of homework
18:04:42 dansmith upgrade items aren't necessarily things that break or need to happen during the upgrade, they're often "this thing that used to be like A is now like B"
18:05:03 melwitt yeah, my concern is that if we don't put it in the upgrade section, people won't see as clearly that they have homework to do before W
18:05:12 dansmith agree
18:05:16 gmann i see. that is good point
18:05:38 dansmith I would put something general in the prelude as a "hey ya'll, we're refactorin' this shiznat over the next few cycles, just FYI"
18:05:43 gmann should I move the complete section in upgrade or keeping scope things in feature as well ?
18:05:46 dansmith and keep the homework bits in upgrade
18:06:39 gmann dansmith: this is prelude, is it fine/enough - https://review.opendev.org/#/c/721548/6/releasenotes/notes/ussuri-prelude-4b96f1244cefcdf4.yaml@36
18:07:31 gmann I need to add the doc link there once that is ready.
18:08:14 dansmith yeah, seems probably like enough, but definitely "see $link for more details on what is changing"
18:08:41 melwitt yeah, that's a todo after we merge this doc on policy changes
18:09:05 gmann ok. let me update the releasenotes
18:09:59 melwitt as for the section for the policy reno, I guess I was thinking to just s/features/upgrade/ for the reno. scope types are kind of a feature (leveraging a keystone feature) but we're going to make them the default, which means operators have homework to do to (1) educating their users to use scoped tokens and (2) get their policies enabled with enforcing scope,
18:10:30 melwitt and then we're going to remove the old policy way in W, so it's not really optional in the end
18:11:04 dansmith A short note in -features might be appropriate too, but if it's in the prelude, I think that's enough
18:11:23 melwitt ok, then either way
18:12:37 sean-k-mooney by the way i assume the we wont be doing something similar for unified limits since we wont have part of it merged in ussuri and its just going to be called out in victoria instead
18:12:54 sean-k-mooney that is a similar hay we are refactroing this change
18:13:24 sean-k-mooney but it wont really affect people for ussuri and they wont have homework yet so i guess its not a concern right now
18:13:33 melwitt yeah nothing yet until V
18:25:54 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
20:56:47 openstackgerrit François Palin proposed openstack/nova stable/train: Add retry to cinder API calls related to volume detach https://review.opendev.org/722142
21:20:58 gmann melwitt: thanks for review. can i fix these 'scoped' word quickly ? if you are around for re+2 - https://review.opendev.org/#/c/720129/14
21:21:11 melwitt gmann: yeah that'd be great
21:22:14 gmann ok
21:22:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
21:23:12 gmann melwitt: ^^ done
21:23:48 melwitt +2
#openstack-nova - 2020-04-23
01:28:45 openstackgerrit Merged openstack/nova master: Pass the actual target in quota class policy https://review.opendev.org/720042
01:52:30 gmann \o/ finally merged
02:06:10 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129
02:30:10 openstackgerrit Jie Li proposed openstack/nova master: replace the "hide_hypervisor_id" to "hw:hide_hypervisor_id" https://review.opendev.org/722187
02:58:37 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Update bp/destroy-instance-with-datavolume SPEC https://review.opendev.org/722194
03:00:40 brinzhang gibi, dansmith, gmann: I was update the bp/destroy-instance-with-datavolume SPEC https://review.opendev.org/#/c/722194, please review if you have free time
03:01:17 gmann melwitt: need your +2 again. fixed one link in reno - https://review.opendev.org/#/c/720129/16
03:02:09 gmann brinzhang: thanks. i will check tomorrow. this is delete-on-termination spec update right ?
03:02:27 brinzhang gmann: thanks
03:02:30 gmann i mean as per latest code we merged as PUT not PATCH
03:02:49 brinzhang gmann: yes, it's the delete-on-termination spec update

Earlier   Later