Tuesday, 2019-04-09

*** wolverineav has quit IRC00:02
*** wolverineav has joined #openstack-nova00:03
*** wolverineav has quit IRC00:07
*** Swami has quit IRC00:08
*** gyee has quit IRC00:09
*** wolverineav has joined #openstack-nova00:20
*** tbachman has joined #openstack-nova00:25
*** wolverineav has quit IRC00:27
*** ttsiouts has joined #openstack-nova00:38
*** ttsiouts has quit IRC00:47
*** ttsiouts has joined #openstack-nova00:48
*** wolverineav has joined #openstack-nova00:49
*** ttsiouts has quit IRC00:52
*** wolverineav has quit IRC00:53
*** lbragstad has joined #openstack-nova00:55
*** ricolin has joined #openstack-nova01:02
*** igordc has quit IRC01:06
*** tpatil has joined #openstack-nova01:07
*** tiendc has joined #openstack-nova01:20
*** _alastor_ has joined #openstack-nova01:27
jungleboyjefried:  Thanks.  Is there time planned to discuss this at the ptg?01:31
*** hongbin has joined #openstack-nova01:33
openstackgerritIvens Zambrano proposed openstack/nova-specs master: RMD Plugin: Energy Efficiency using CPU Core P-State control The power state of a core can be setup between a minimum and the maximum frequency on the cores as defined in the factory. Each core on a CPU can be defined individually to perform at specific f  https://review.openstack.org/65102401:34
*** nicolasbock has quit IRC01:39
*** _alastor_ has quit IRC01:40
*** ricolin_ has joined #openstack-nova01:50
*** ricolin has quit IRC01:50
*** tpatil has quit IRC02:17
openstackgerritBoxiang Zhu proposed openstack/nova master: Cleanup migrate flags  https://review.openstack.org/65105602:17
*** tpatil has joined #openstack-nova02:25
*** hongbin has quit IRC02:35
openstackgerritzhufl proposed openstack/nova master: Remove conductor_api and cells_rpcapi from manager.py  https://review.openstack.org/65105902:35
*** whoami-rajat has joined #openstack-nova02:37
*** hongbin has joined #openstack-nova02:38
*** igordc has joined #openstack-nova02:40
efriedjungleboyj: Nothing yet, swhat I was going to ask you about. We could do 11:15-lunch (with a break at 11:50 for team photo) if that works for you. Or after lunch, any time except 1400-1515.02:42
*** boxiang has quit IRC02:42
*** boxiang has joined #openstack-nova02:42
jungleboyjI don't have anything scheduled yet so I am flexible. Let's see what the team has, if anything, and talk later in the week.02:44
jungleboyjefried: on vacation this week so will have smcginnis follow up.02:45
efriedsure thing, thanks jungleboyj02:45
*** cfriesen has quit IRC02:46
*** hongbin has quit IRC02:49
*** hongbin has joined #openstack-nova02:51
*** Sundar has quit IRC02:57
*** tpatil has quit IRC02:57
openstackgerritMerged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7)  https://review.openstack.org/57497403:22
openstackgerritmelanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement  https://review.openstack.org/63807303:38
openstackgerritmelanie witt proposed openstack/nova master: Use instance mappings to count server group members  https://review.openstack.org/63832403:38
*** cfriesen has joined #openstack-nova03:40
*** N3l1x has quit IRC03:42
*** tpatil has joined #openstack-nova03:50
*** lbragstad has quit IRC03:51
openstackgerritBoxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule  https://review.openstack.org/64995303:53
*** imacdonn_ has quit IRC04:02
*** imacdonn_ has joined #openstack-nova04:03
*** udesale has joined #openstack-nova04:04
*** hongbin has quit IRC04:05
*** bhagyashris has joined #openstack-nova04:13
openstackgerritMerged openstack/nova master: Add placeholder migrations for Stein backports  https://review.openstack.org/65096404:29
*** markvoelker has quit IRC04:31
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup  https://review.openstack.org/60396904:44
*** dpawlik has joined #openstack-nova04:45
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup  https://review.openstack.org/60396904:46
*** zhongjun2 has quit IRC04:46
*** wolverineav has joined #openstack-nova04:49
*** dpawlik has quit IRC04:50
*** wolverineav has quit IRC04:54
*** tpatil has quit IRC04:58
*** sidx64 has joined #openstack-nova05:08
openstackgerritTetsuro Nakamura proposed openstack/nova master: Add in_tree field to RequestGroup object  https://review.openstack.org/64953405:10
openstackgerritTetsuro Nakamura proposed openstack/nova master: Add get_compute_nodes_by_host_or_node()  https://review.openstack.org/65087705:10
openstackgerritTetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree  https://review.openstack.org/65087805:10
openstackgerritTetsuro Nakamura proposed openstack/nova master: Query `in_tree` to placement  https://review.openstack.org/64953505:10
*** igordc has quit IRC05:11
*** ratailor has joined #openstack-nova05:11
eanderssonI still wish you could add your own filters and weights as plugins.05:28
eanderssonInstead of having to roll your own version of nova and drop them in the appropriate folders.05:29
*** tpatil has joined #openstack-nova05:32
*** _alastor_ has joined #openstack-nova05:33
openstackgerritBoxiang Zhu proposed openstack/nova master: Use the functional test test_parallel_evacuate_with_server_group  https://review.openstack.org/64996305:36
*** _alastor_ has quit IRC05:46
*** sridharg has joined #openstack-nova05:50
*** udesale has quit IRC05:52
openstackgerritMerged openstack/nova master: Remove query_client from resource_tracker  https://review.openstack.org/65061605:53
*** ricolin_ has quit IRC05:58
*** ileixe has quit IRC06:01
*** ratailor has quit IRC06:01
*** ileixe has joined #openstack-nova06:05
*** ccamacho has joined #openstack-nova06:12
*** ratailor has joined #openstack-nova06:13
*** ricolin has joined #openstack-nova06:22
*** boxiang has quit IRC06:27
*** dpawlik has joined #openstack-nova06:27
*** pcaruana has joined #openstack-nova06:30
*** markvoelker has joined #openstack-nova06:32
*** udesale has joined #openstack-nova06:33
*** slaweq has joined #openstack-nova06:47
*** cfriesen has quit IRC06:48
*** ivve has joined #openstack-nova07:06
*** markvoelker has quit IRC07:06
*** phasespace has quit IRC07:08
*** rpittau|afk is now known as rpittau07:12
*** tesseract has joined #openstack-nova07:13
*** awalende has joined #openstack-nova07:13
*** sidx64 has quit IRC07:13
*** jangutter has quit IRC07:15
*** yankcrime has quit IRC07:15
*** jangutter_ has joined #openstack-nova07:15
*** sidx64 has joined #openstack-nova07:15
*** tpatil has quit IRC07:16
*** slaweq has quit IRC07:17
kashyapefried: When you're about, I'd suggest to _not_ approve (although it was "approved" for Stein) this spec right away: https://review.openstack.org/#/c/642030/ (Re-propose the spec to allow specifying a list of CPU models)07:17
*** slaweq has joined #openstack-nova07:17
kashyapThe more I think of it, there are more questions than answers.  And the author of the spec from Stein seems AWOL.07:18
*** tosky has joined #openstack-nova07:20
*** tpatil has joined #openstack-nova07:21
*** tssurya has joined #openstack-nova07:28
openstackgerritKashyap Chamarthy proposed openstack/nova-specs master: Add "CPU selection with hypervisor consideration" spec  https://review.openstack.org/64581407:29
bauzaskashyap: just leave a comment in https://review.openstack.org/#/c/642030/ saying you'd like to not have the spec quick approved07:31
bauzasquickly* (or fast)07:31
*** ileixe has quit IRC07:32
*** tosky has quit IRC07:33
*** tosky has joined #openstack-nova07:33
*** boxiang has joined #openstack-nova07:33
*** ileixe has joined #openstack-nova07:35
*** ileixe has quit IRC07:35
*** zhubx has joined #openstack-nova07:36
*** zhubx has quit IRC07:36
*** boxiang has quit IRC07:37
*** boxiang has joined #openstack-nova07:38
*** sidx64 has quit IRC07:43
* kashyap clicks07:43
kashyapbauzas: I'm still thinking of the design.  I didn't write it, the original person who wrote for Stein isn't answering questions on IRC or on the spec07:44
kashyapbauzas: I'm writing a more thorough comment after some thinking last evening.07:45
*** ralonsoh has joined #openstack-nova07:48
kashyapbauzas: Maybe a silly question: Can tenant users create flavors?07:50
bauzaskashyap: there is no silly question07:50
bauzaskashyap: flavors are managed by admins, but that's just a policy07:50
kashyapRight07:50
bauzasthat's the main different between image metadata and flavor extra specs07:51
bauzasones are admin-defined, the others are user-defined07:51
kashyapbauzas: Ah, noted; so flavor extra_specs are user-defined.07:54
kashyapThanks!07:55
*** jonher_ has joined #openstack-nova07:57
bauzaskashyap: uh that's not what I said :)07:58
*** lee1 has joined #openstack-nova07:58
bauzassorry, I flipped the answer07:58
*** jonher has quit IRC07:58
*** ralonsoh has quit IRC07:58
*** lyarwood has quit IRC07:58
*** frickler has quit IRC07:58
*** jonher_ is now known as jonher07:58
kashyapErr, it's the other way round.07:58
*** ralonsoh has joined #openstack-nova07:58
bauzaskashyap: https://docs.openstack.org/nova/latest/configuration/policy.html07:59
*** frickler has joined #openstack-nova07:59
bauzas  os_compute_api:os-flavor-extra-specs:create Default rule:admin_api  Operations  POST /flavors/{flavor_id}/os-extra_specs/07:59
bauzasbut as a user, you can see the flavor extra specs08:00
*** dtantsur|afk is now known as dtantsur08:00
kashyapNod08:00
*** lee1 is now known as lyarwood08:00
openstackgerritKunpeng Zhang proposed openstack/nova master: Enhance live-migration progress log for memory and block data  https://review.openstack.org/65062108:00
*** rcernin has quit IRC08:01
*** ccamacho has quit IRC08:01
*** markvoelker has joined #openstack-nova08:03
*** ileixe has joined #openstack-nova08:05
*** ttsiouts has joined #openstack-nova08:05
openstackgerritDakshina Ilangovan proposed openstack/nova-specs master: Implements: blueprint nova-local-resource-management-that-uses-rmd  https://review.openstack.org/65113008:06
*** phasespace has joined #openstack-nova08:08
*** priteau has joined #openstack-nova08:15
*** wolverineav has joined #openstack-nova08:15
*** luksky has joined #openstack-nova08:15
kashyapbauzas: One more: tenant users can't even set traits on flavors right?  (My ans: They can't, since flavors are created by admins.)08:17
kashyaps/flavors right?/flavors, right?/08:17
bauzaskashyap: you don't "set" a trait on a flavor, but you rather add a trait as an extra spec field08:17
bauzasso, yeah to what you said08:17
kashyapbauzas: Noted, thanks for correcting :-)08:17
bauzasyou 'set' a trait on a RP08:18
*** johanssone has quit IRC08:18
kashyap(Ah, Resource Provider; I don't much about them.  For now, I'll table that topic. )08:18
bauzaskashyap: no worries, just explaining for you and also other folks08:18
kashyapThx.08:19
*** wolverineav has quit IRC08:20
kashyapyaawang: jackding: Hey, on this "select CPU model from a list" spec (https://review.openstack.org/#/c/642030/), I have some more unanswered design questions.08:20
kashyapyaawang: jackding: I think we should sort them out first.  Probably I will send an email to the 'openstack-discuss' list and Cc you both.08:20
*** johanssone has joined #openstack-nova08:24
*** zbr has quit IRC08:28
*** sidx64 has joined #openstack-nova08:28
*** yankcrime has joined #openstack-nova08:33
*** markvoelker has quit IRC08:36
*** ttsiouts has quit IRC08:37
*** ttsiouts has joined #openstack-nova08:37
yaawangkashyap: OK, do we need to open a zoom call to figure out some of the questions?08:39
kashyapWhat is a "zoom call"?08:39
*** derekh has joined #openstack-nova08:40
kashyapI think I will write up the questions, so that those who are not present can also read them.08:40
kashyap(And it serves as a record as well.)08:40
*** ttsiouts has quit IRC08:40
*** ttsiouts has joined #openstack-nova08:40
yaawangs/zoom call/online meeting/08:42
*** tkajinam has quit IRC08:43
yaawangkashyap: OK, I agree with you. When can you send the email?08:43
kashyapyaawang: By end of today (I'm in CEST)08:44
yaawangkashyap: Got it, thanks.08:46
openstackgerritBoxiang Zhu proposed openstack/nova-specs master: Expose live migration tunnelled in rest api  https://review.openstack.org/65113908:48
*** Luzi has joined #openstack-nova08:56
*** bhagyashris has quit IRC08:57
*** davidsha has joined #openstack-nova09:06
*** luksky has quit IRC09:15
*** bhagyashris_ has joined #openstack-nova09:20
*** jaosorior has quit IRC09:24
openstackgerritBoxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule  https://review.openstack.org/64995309:29
*** jaosorior has joined #openstack-nova09:31
openstackgerritLee Yarwood proposed openstack/nova-specs master: Re-propose stable device rescue for Train  https://review.openstack.org/65115109:33
*** sidx64 has quit IRC09:34
*** cdent has joined #openstack-nova09:39
*** bhagyashris_ has quit IRC09:40
*** sidx64 has joined #openstack-nova09:45
*** tpatil has quit IRC09:47
*** sidx64 has quit IRC09:51
*** sidx64 has joined #openstack-nova09:54
*** udesale has quit IRC09:57
*** udesale has joined #openstack-nova09:58
*** psachin has joined #openstack-nova09:59
frickleris there a list of todos regarding eliminating nova-network from the docs? this should be added to it https://docs.openstack.org/nova/latest/admin/networking-nova.html#metadata-service-deploy10:07
*** luksky has joined #openstack-nova10:08
*** gary_perkins_ has quit IRC10:11
*** gary_perkins has joined #openstack-nova10:11
*** ttsiouts has quit IRC10:25
*** ttsiouts has joined #openstack-nova10:26
*** ttsiouts has quit IRC10:30
*** markvoelker has joined #openstack-nova10:33
*** bbowen has quit IRC10:36
*** sidx64 has quit IRC10:41
*** nicolasbock has joined #openstack-nova10:46
*** tetsuro has quit IRC10:46
*** ttsiouts has joined #openstack-nova10:46
*** tbachman has quit IRC10:48
*** owalsh has quit IRC10:53
*** owalsh_ has joined #openstack-nova10:53
openstackgerritKashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec  https://review.openstack.org/50672010:54
*** udesale has quit IRC10:56
kashyapbauzas: Please don't "-1" based on "bad feelings": https://review.openstack.org/#/c/642030/10:58
kashyapIf you have a good rationale, then do so.  Otherwise, just leave a comment.10:58
sean-k-mooneykashyap: i have not read it but i think -1 form a core because they have bad feels about something is not unwarrented10:59
kashyapbauzas: Also, no -- just using the plural `cpu_models` is _not_ "simple".  It can cause confusion10:59
kashyapPlease read the commit message, where I outlined _why_ we should use the name I proposed.10:59
kashyapsean-k-mooney: Well, I see the point.  But I'd prefer a -1 to be backed with rationale.  (In this case bauzas did ask a few valid questions, though.  It's all fine.)11:00
kashyapMaybe I'm feeling a bit cranky with too many things going on ... don't take me _too_ seriously :-)11:01
sean-k-mooneykashyap: when you have core right you can be more granular as you can -2 when you really have stong feeling somthing shoudl not be done11:01
kashyapNod11:02
sean-k-mooneykashyap: by the way cpu_model_list = Conroe,Penryn,Nehalem,Westmere,SandyBridge,IvyBridge,Haswell,Broadwell,Skylake-Client,Skylake-Server11:03
sean-k-mooneyi assume that would prefer Conroe and proceed left to right11:03
*** sidx64 has joined #openstack-nova11:04
openstackgerritDakshina Ilangovan proposed openstack/nova-specs master: Nova local resource management that uses RMD  https://review.openstack.org/65113011:04
sean-k-mooneyin other words the operator is enabling the older cpu models first thereby ensuring the maxium compatiblity11:05
kashyapsean-k-mooney: This whole idea of "CPUs must be oredered from least featureful to most" is flaky to me.11:05
kashyap(I've asked the QEMU and libvirt devs for some more input, I'll respond on the change once I have clearer idea.)11:05
sean-k-mooneyi think it will work fine11:06
kashyapsean-k-mooney: It is more tedious, isn't it, to get the order right, _while_ being aware of what CPUs one has locally?11:06
sean-k-mooneywe have prescedent for this already in neutron11:06
sean-k-mooneyit is more tedious but i doubt may people would list all of them11:06
sean-k-mooneytypically datacenters have only a handful of generations deployed concurrently11:07
*** markvoelker has quit IRC11:07
sean-k-mooneyso i woudl expect the list to contain 2-3 in general11:07
sean-k-mooneythere is no point in listing a generation older then any of your servers afterall11:08
kashyapHmm, okay, that's somewhat palatable11:09
sean-k-mooneyso somthign like cpu_model_list = nehalam,ivybridge,skylake-server woudl be more typical11:09
*** zbr has joined #openstack-nova11:09
*** sidx64 has quit IRC11:15
*** sidx64 has joined #openstack-nova11:21
kashyapRight; but who knows11:25
*** sidx64 has quit IRC11:26
*** sidx64 has joined #openstack-nova11:28
*** mvkr has joined #openstack-nova11:30
kashyapsean-k-mooney: Thanks for the comments11:34
kashyapsean-k-mooney: It seems like I have suddenly "inherited" this spec, as the original proposer for Stein is nowhere to be seen.11:34
sean-k-mooneyno worries. i need to write one sepc and then start makeing my way through the spec review queue11:37
kashyapThe more I think about this spec, the more questions arise.11:37
kashyap(And yes, I'll move the rationale from commit message to the spec itself.)11:38
sean-k-mooneyi wrote a version of this sepc 3 years ago to satify telefonic. tye wanted to specify the cpu_model in the flavor. so i proposed adding a new cpu_mode=dynamic which allowed the flavor to set the cpu_model that was required11:39
sean-k-mooneythat spec predated placement so i think i also had a new schduler filter to do the compatiblity check11:39
sean-k-mooneytelcos have wanted somthign like this for a long time but its a blance between cloudines and hardware defined software11:41
sean-k-mooneyin this iteration the use of traits to exrpess the workload requirements is a nice abstration11:42
cdentjaypipes++11:45
jaypipescdent: ?11:46
cdentrsd spec11:46
jaypipesah11:46
jaypipesjust starting off spec review day...11:46
kashyapsean-k-mooney: What do you mean by "there is no easy way using qemu or libvirt for an operator to check the cpu model flags"?11:47
cdentkeep rolling like that and it should be a fine day11:47
kashyapsean-k-mooney: You can trivially see what flags QEMU binary supports -- surely you that11:47
kashyapa/"QEMU binary"/"a given QEMU binary on the host"/11:48
sean-k-mooneyjaypipes: the reason that intel is proposeing that spec is because i pushed for that change in architure after it became apparent that doing it outside of nova had several disavantages11:48
sean-k-mooneyjaypipes: one of the main disadvanatges beside the fact taht efforts to do this outside of nova have failed at lest 3 time was when you go done that path using openstack at all becomes questionable11:49
*** bbowen has joined #openstack-nova11:50
jaypipessean-k-mooney: so square peg, round hole it into Nova and that problem will go away? :)11:53
sean-k-mooneyjaypipes: part of the motivation of enableing RSD as a composible hypervior under nova is to ensure that end users can continue to use openstack api without needing to know their instances are provide by rsd but operators can leverage it11:53
jaypipessean-k-mooney: that is precisely why I believe it needs to be outside of Nova.11:53
sean-k-mooneyjaypipes: do you belive we shoudl delete the ironic driver?11:54
jaypipessean-k-mooney: no.11:54
sean-k-mooneythe integration will be almost identical11:54
jaypipessean-k-mooney: no it won't.11:54
jaypipesspecifically, having to create flavors on the fly11:55
sean-k-mooneywell i spend a year modeling it on how ironic worked with minor tweeks11:55
sean-k-mooneyjaypipes: that is not required11:55
sean-k-mooneythat was a suggesting to make testing eaier11:55
sean-k-mooneythe flavor it create just contain the reouces request for the custom_resouce class11:56
jaypipessean-k-mooney: I just don't think it's a good idea, sorry.11:56
sean-k-mooneyok but for the record i did bring this idea up at the first denver ptg and the vancour summit to make sure people were ok with it11:57
sean-k-mooneyyou werent at teh vancour summit11:57
sean-k-mooneybut i was pretty sure i ran this by you at some point11:57
*** sidx64 has quit IRC11:59
kashyapgibi: On your (good) question on the change, please read this spec, too (if you have time).  It aims to answer your question: https://review.openstack.org/#/c/645814/4/specs/train/approved/cpu-selection-with-hypervisor-consideration.rst11:59
*** tbachman has joined #openstack-nova11:59
*** ttsiouts has quit IRC12:00
*** jmlowe has quit IRC12:01
jaypipessean-k-mooney: OK, but for the record, I've had the exact same position for 4 years since Intel proposed it when I was working for Mirantis.12:01
jaypipes:)12:01
*** ttsiouts has joined #openstack-nova12:01
jaypipesand you were working for Intel :)12:01
*** jmlowe has joined #openstack-nova12:02
*** nicolasbock has quit IRC12:02
*** nicolasbock has joined #openstack-nova12:02
sean-k-mooney:) ok  yes but i guess we have always dissagreed then we never tought vlance was a viable approch in my team12:02
gibikashyap: ack. There is too many specs :)12:03
sean-k-mooneyit lost the cloud abstration meaning existing workloads/workflows needed to be modifyed to know what rsd was12:03
jaypipessean-k-mooney: if you think RSD is "cloudy" as opposed to just a tool for operators to reduce power consumption in their datacenters, then I suppose you might think that.12:07
jaypipessean-k-mooney: however, I don't. I don't see RSD as anything other than a compute node dynamic composer. I don't see it as the next generation of "packaging" for a workload.12:08
jaypipessean-k-mooney: it's hardware, plain and simple. It's not the next Kubernetes abstraction for a new type of workload.12:08
sean-k-mooneyyes i agree which is why i think openstacks apis need to be the abstration12:09
jaypipessean-k-mooney: we will just have to agree to disagree on this topic :)12:09
sean-k-mooneyi think of it as a bearmental hypervior12:09
sean-k-mooneylike ironic12:09
*** davidsha has quit IRC12:10
*** elod has quit IRC12:11
*** elod has joined #openstack-nova12:11
kashyapgibi: Hehe, sorry.  Yeah, context overload; completely understand it.12:13
kashyapgibi: Take a look at it, on a non-spec day; I'll assume everyone is maxed out today12:14
gibikashyap: I kept that spec open, but I move by the etherpad order https://etherpad.openstack.org/p/nova-spec-review-day12:14
kashyap(And looking at too many specs parallely will only splinter the attention to hell and back, which is costly.)12:14
*** wolverineav has joined #openstack-nova12:16
*** sidx64 has joined #openstack-nova12:18
jaypipessean-k-mooney: "bearmental hypervior" <-- nice.12:18
kashyapFolks: On line-42 I added a spec I meant to add on 04-Apr (as mentioned on the list to Eric's email on pre-PTG review); didn't post it in the last minute :-)12:19
*** wolverineav has quit IRC12:20
sean-k-mooney:)12:21
*** tiendc has quit IRC12:22
openstackgerritMerged openstack/nova master: Improve test coverage of nova.privsep.path.  https://review.openstack.org/64860112:22
openstackgerritMerged openstack/nova master: Improve test coverage of nova.privsep.fs.  https://review.openstack.org/64860212:22
gibikashyap: you really want me to read that spec :)12:23
openstackgerritMerged openstack/nova master: Improve test coverage of nova.privsep.fs, continued.  https://review.openstack.org/64860312:24
*** ratailor has quit IRC12:24
kashyapgibi: Hehe, the above mentioned line-42 one is about Secure Boot one (which jaypipes reviewed back in the day; before we identified work to be done in lower layers)12:25
gibikashyap: ohh, I looked at the line 41 instead.12:25
kashyapgibi: Yep, that is fairly uncontroversial.  (Says the guy who proposed it.)12:25
gibikashyap: anyhow I'm reading the spec at l41 now :)12:25
kashyapThanks!12:25
kashyapI need to be AFK in 35 mins; will respond on the change for any feedback12:26
kashyapjaypipes: If you still have the stomach for it this week, might want to have a gander at the Secure Boot thing, in your "copious free time" :D12:26
* kashyap has posted periodic updates on the spec over the year, as work got completed in lower layers (OVMF, QEMU and libvirt)12:26
jaypipeskashyap: yep, today is spec review day.12:27
* kashyap is aware; but I'm aware of the limited resource that is human attention. So I don't expect people to get to it today12:30
*** jamesdenton has quit IRC12:33
openstackgerritKashyap Chamarthy proposed openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models  https://review.openstack.org/64203012:37
*** tetsuro has joined #openstack-nova12:37
*** tetsuro has quit IRC12:40
bauzaskashyap: sean-k-mooney: sorry was afk for lunch12:40
bauzasso I missed your pings12:40
*** maciejjozefczyk has quit IRC12:40
bauzasdon't take a -1 for a passive-aggressive method12:40
bauzasit's just "I disagree with the current patch, because of : X, Y"12:40
kashyapbauzas: No worries; it's all sorted12:41
bauzasand my -1 is not about the naming, but rather about the fact that operators should provide a list ordered12:41
kashyapbauzas: Yeah, saw your question; see the response from Sean and me...12:41
sean-k-mooneybauzas: yes i know. that is how i use it too.12:41
bauzasI'll look at the comments, for the moment, I'm looking at other spec12:42
*** priteau has quit IRC12:42
*** openstackgerrit has quit IRC12:44
*** dtantsur is now known as dtantsur|brb12:46
*** Luzi_ has joined #openstack-nova12:46
*** openstackgerrit has joined #openstack-nova12:48
openstackgerritTheodoros Tsioutsias proposed openstack/nova master: Add instance hard delete  https://review.openstack.org/57020212:48
openstackgerritTheodoros Tsioutsias proposed openstack/nova master: Add requested_networks to RequestSpec  https://review.openstack.org/57020112:48
openstackgerritTheodoros Tsioutsias proposed openstack/nova master: Enable rebuild for instances in cell0  https://review.openstack.org/57020312:48
*** lbragstad has joined #openstack-nova12:49
openstackgerritTheodoros Tsioutsias proposed openstack/nova master: Introduce the PENDING instance state  https://review.openstack.org/56647312:49
openstackgerritTheodoros Tsioutsias proposed openstack/nova master: Allow rebuild for instances in PENDING state  https://review.openstack.org/63758512:49
*** Luzi has quit IRC12:49
efriedkashyap: ack12:50
sean-k-mooneyits surpring how often "sudo rm -rf /var/lib/docker/" fixs your docker issues12:51
efriedI at least diff from the last release's version before doing that; this one has changed substantially so I'll wait12:51
efriedWhat's the adage? "If you try to solve a problem using docker, now you have two problems." ?12:52
efrieddansmith: Would you please update the channel topic to something like12:53
efriedWelcome to Train pre-PTG spec review day #1: https://etherpad.openstack.org/p/nova-spec-review-day12:53
*** jroll has quit IRC12:55
*** owalsh_ is now known as owalsh_afk12:58
*** jroll has joined #openstack-nova12:59
*** mdbooth has quit IRC12:59
*** mdbooth has joined #openstack-nova12:59
*** mchlumsky has joined #openstack-nova13:00
*** eharney has joined #openstack-nova13:00
*** dikonoor has joined #openstack-nova13:04
*** sidx64 has quit IRC13:05
*** dikonoor has quit IRC13:08
*** tbachman has quit IRC13:10
openstackgerritHuqiang Wang proposed openstack/nova-specs master: Separate the vCPUs into different pools based on priority  https://review.openstack.org/64988213:13
*** tbachman has joined #openstack-nova13:16
*** Luzi_ has quit IRC13:17
*** amodi has joined #openstack-nova13:19
openstackgerritDakshina Ilangovan proposed openstack/nova-specs master: Nova LLC allocation - RMD plugin for RDT CAT  https://review.openstack.org/65123313:19
openstackgerritLee Yarwood proposed openstack/nova master: Use migration_status during volume migrating and retyping  https://review.openstack.org/63722413:21
*** awaugama has joined #openstack-nova13:24
*** dakshina-ilangov has joined #openstack-nova13:25
*** belmoreira has joined #openstack-nova13:26
*** ChanServ sets mode: +o dansmith13:28
*** priteau has joined #openstack-nova13:28
*** IvensZambrano has joined #openstack-nova13:28
*** dansmith changes topic to "Welcome to Train pre-PTG spec review day #1: https://etherpad.openstack.org/p/nova-spec-review-day -- Current runways: https://etherpad.openstack.org/p/nova-runways-train -- This channel is for Nova development. For support of Nova deployments, please use #openstack."13:28
*** tbachman has quit IRC13:32
*** udesale has joined #openstack-nova13:36
kashyapsean-k-mooney: On "Docker", you're so 2014.  'Everyone' has moved on from Docker to "CRI-O" and "podman", etc.13:37
kashyap(Please update your "container jargon" :D)13:37
* kashyap stops trolling, lest he gets banned13:37
*** tbachman has joined #openstack-nova13:38
*** maciejjozefczyk has joined #openstack-nova13:38
sean-k-mooneykashyap: i am using docker and plan to never use podman. i might use CRI-O13:38
kashyapsean-k-mooney: I was massively trolling; sorry.  (I have no clue about their compatibilities.)13:39
sean-k-mooneypodman has 1:1 commandline compatible with docker13:41
sean-k-mooneyor the docker cli13:41
*** lpetrut has joined #openstack-nova13:42
*** malekmar has joined #openstack-nova13:42
sean-k-mooneycri-o is interesting but its non tivial to setup currently13:42
*** malekmar has quit IRC13:42
*** mriedem has joined #openstack-nova13:43
mriedemmordred: as our resident compute api/sdk opinion czar, i'd like your opinion on this spec https://review.openstack.org/#/c/638629/9/specs/train/approved/add-locked-reason.rst@19813:43
mriedemspecifically the response format for those new fields13:43
mriedemi.e. nested or flat13:44
*** liuyulong|away is now known as liuyulong13:44
kashyapgibi: Thanks!  (I spent a lot of time wordsmithing to get words right in that spec)13:45
*** belmorei_ has joined #openstack-nova13:46
*** phasespace has quit IRC13:48
*** belmoreira has quit IRC13:48
*** awalende has quit IRC13:58
*** awalende has joined #openstack-nova13:59
*** maciejjozefczyk has quit IRC13:59
*** mlavalle has joined #openstack-nova14:00
*** awalende has quit IRC14:03
*** davidsha_ has joined #openstack-nova14:04
*** priteau has quit IRC14:04
*** lpetrut has quit IRC14:04
*** ttsiouts has quit IRC14:06
*** ttsiouts has joined #openstack-nova14:07
*** ttsiouts has quit IRC14:09
*** ttsiouts has joined #openstack-nova14:09
mriedemtssurya: some questions in your ironic power state sync spec https://review.openstack.org/#/c/636132/14:11
mriedemdansmith: ^ you should probably review that as well14:11
tssuryamriedem: ack, looking14:11
mriedemjaypipes maybe too since he loves ironic nowadays14:11
jaypipesmriedem: errmmm, not quite :)14:12
jaypipesbut I'll review regardless.14:12
dansmithmriedem: on meetings for the next couple hours, but willt ry14:15
kashyapFrelling rST14:22
*** belmoreira has joined #openstack-nova14:22
mriedemgibi: i've replied to your questions in the cross-cell resize re-proposal https://review.openstack.org/#/c/642807/14:23
mriedemsuppose dansmith and melwitt should look at that one as well since they are familiar with the original in stein14:23
*** belmorei_ has quit IRC14:25
* alex_xu has wonderful spec review day with have cold and a lot of snot and no enough sleep and full day meeting14:25
kashyapalex_xu: Gosh, it is 22:26.  Nothing is more important than sleep...14:26
alex_xu\o/ sleep now14:27
*** belmoreira has quit IRC14:27
* kashyap plugs the fantastic book by the amazing Matthew Walker (https://www.penguin.co.uk/books/295/295665/why-we-sleep/9780141983769.html)14:27
mriedemalex_xu: i still have some chinese cold medicine from the shenzhen airport i can send you :)14:27
mriedemi don't know what it says on the packaging but i know i'm only supposed to take 2 of each every 12 hours14:27
*** dtantsur|brb is now known as dtantsur14:30
openstackgerritStephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec  https://review.openstack.org/63873414:37
*** belmoreira has joined #openstack-nova14:37
*** cfriesen has joined #openstack-nova14:39
stephenfinkashyap: Fair to say https://review.openstack.org/#/c/625216/ means https://review.openstack.org/#/c/651139/ is unnecessary?14:40
* kashyap looks14:40
*** N3l1x has joined #openstack-nova14:41
*** owalsh_afk is now known as owalsh14:41
kashyapstephenfin: Just took a cursory look, so they're proposing to expose _tunnelled via REST API.  That's baloney14:42
kashyapWe don't want _tunnelled at all, we will deprecate it, as you know14:42
*** igordc has joined #openstack-nova14:42
stephenfinkashyap: Yup, that's what I was thinking but I just wanted to be sure it was as baloney as I thought it was14:43
kashyap"We" as in, once we bump the min versions to have hypervisor-native TLS, then Nova can nuke _tunnelled support14:43
openstackgerritEric Fried proposed openstack/nova-specs master: Tools & docs for backlog & abandoned spec process  https://review.openstack.org/64880014:44
efriedstephenfin: Did I do that right? ^14:44
* kashyap also links to: http://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/secure-live-migration-with-qemu-native-tls.rst14:44
kashyapstephenfin: Aside: please deliver me from my misery by sharing the "genuine table" syntax.  I'm only seeing these "naked tables": https://kashyapc.fedorapeople.org/Plain-rendering-of-table-Sphinx.png14:44
kashyap(Also, I like the .. code-block: text tip from efried; it's visually clean and immediately shows what a user wants)14:45
stephenfinkashyap: Ahh, that's the theme's fault. I'd been testing with the default Sphinx theme14:45
kashyap(s/what a user wants/what the API entails/)14:45
stephenfinBad openstackdocstheme14:45
*** belmoreira has quit IRC14:46
stephenfinkashyap: OK, ignore that comment so. That's certainly more difficult to read that one would like14:46
kashyapYeah, phew.  Thanks for confirming that I'm missing to see something that only you seem to see :-)14:46
kashyaps/that I'm missing/that I'm _not_ missing/14:46
stephenfinefried: 'ish. You don't need to define the 'nodeps' testenv14:46
efriedstephenfin: There was another place where the lack of (even the ability to request) table borders was very annoying.14:46
gibimriedem: thanks. the cross resize patch looks good to me. I did +1 it only as I feel others should approve it14:47
efriedstephenfin: I figured I had the choice between defining that env or repeating 'deps=' in both, right?14:47
efriedfigured the former was more DRY-ish and less prone to future slippage14:47
efriedcan flip it if you prefer it the other way, whatevs.14:48
stephenfinefried: Not really. deps for a given section will inherit from '[testenv]' by default14:48
stephenfinSo you've reverted back to 'deps = -r{toxinidir}/doc/requirements.txt' for those two sections14:48
efriedeh?14:48
*** lpetrut has joined #openstack-nova14:48
efriedEven though I said envdir= ?14:48
efriedokay, I'll twiddle it again.14:49
stephenfinyeah, envdir has no bearing on deps14:49
efriedight14:49
mriedemkashyap: stephenfin: gibi: i've left several comments and questions in this baselineHypervisorCPU spec https://review.openstack.org/#/c/645814/ and i must be missing something that everyone else understands about what this solves14:49
kashyapWill look14:49
openstackgerritEric Fried proposed openstack/nova-specs master: Tools & docs for backlog & abandoned spec process  https://review.openstack.org/64880014:49
stephenfinother than if you use the same envdir with different deps, in which case you get the aforementioned rebuilding on environment each time14:50
efriedwhee14:50
efrieddone14:50
efried---^14:50
efriedThanks for the help stephenfin14:50
*** jistr is now known as jistr|call14:51
gibimriedem: I think https://review.openstack.org/#/c/645814/ and https://review.openstack.org/#/c/642030/ are connected14:53
gibimriedem: so when nova will automatically select a specific cpu_model from a list of models it will select a better suited one14:53
mriedemthe former doesn't mention anything about the latter14:54
*** maciejjozefczyk has joined #openstack-nova14:54
*** maciejjozefczyk has quit IRC14:55
stephenfinefried: +2'd14:55
efriedthank you sir.14:55
gibimriedem: that is true14:55
*** lbragstad has quit IRC14:56
gibimriedem: kashyap knows more about the connection14:56
*** lbragstad has joined #openstack-nova14:56
kashyapI did mention about this https://review.openstack.org/#/c/645814/ in https://review.openstack.org/#/c/645814/14:57
*** NostawRm has joined #openstack-nova14:57
mriedemi assume you meant to link to https://review.openstack.org/#/c/642030/14:57
mriedemwhich i haven't read14:57
kashyapmriedem: The "executive summary" is that the two libvirt APIs Nova uses today don't take account what the host KVM, QEMU and libvirt are capable of, when computing CPU models.  And the proposed two new APIs will solve a class of issues.14:57
kashyapAmong other things, Nova can now ask: "Are CPU flags X and Y supported by KVM, QEMU and libvirt on the host"?14:58
kashyapHow does that help operators?14:58
kashyapIt gives them more _useful_ (and in some cases _secure_ -- e.g. CPU flags introduced to solve Meltdown/Spectre) guest CPU configuration14:59
kashyap(Not everything is linked to migration.)14:59
kashyapI'll respond on the review, to save some typing.14:59
dansmithkashyap: are you talking about for scheduling or for generating more optimal xml for a guest?14:59
mriedemit's not clear to me if the operator is doing anything here, or if operators today are doing x to workaround limitations in nova's libvirt driver using these older apis15:00
mriedemthe spec just isn't clear to me on what the end user visible benefit is15:01
mriedemi'm sure there is one, but it's just not clear to me15:01
*** ttsiouts has quit IRC15:01
mriedem1. use new apis, 2. ?, 3. profit.15:01
kashyapdansmith: Not scheduling.  In some ways you can call it "optimal XML for a guest", but not everything is about XML generation.  It is more about how Nova's libvirt driver can take into account multiple important factors (listed in the spec) when coming up with guest CPUs15:02
mordredmriedem: I think either thing is fine from an openstacksdk POV - but I could see the shift from bool to dict being maybe a little more annoying for the more staticly typed folks like go - whereas the flat approach like it is in the notification payload would be potentially friendlier to deal with there15:02
mriedemi should probably re-watch your summit talk that is related to this15:02
*** ttsiouts has joined #openstack-nova15:02
dansmithkashyap: okay, I15:02
mordredmriedem: so I think I'd vote, in this case, for flat, mostly because of the existence of the locked key already15:02
dansmithhave only skimmed, but.. probably need to be more clear about that15:02
kashyapmriedem: It is not directly a clean one-to-one mapping of: "if you click on this button, elephants will dance on your screen"15:02
kashyapmriedem: The operator doesn't have to do anything much here15:03
mriedemis there a very obvious case of "this is an issue we have today which is a limitation due to using the older apis which would be solved by using the new"15:03
mriedemlike an actual example15:03
kashyapYes, let me link to the code15:04
mriedemmordred: ok, if you can take a sec to comment on the spec that would go a long way i think15:04
mordredsure!15:04
kashyapmriedem: libvirt upstream added the two APIs (partly) based on the need that came out of Nova, noted here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3947,#L395815:05
kashyap(That comment should be removed, now that the libvirt RFE I filed is fixed.)15:05
openstackgerritsean mooney proposed openstack/nova-specs master: Libvirt: add vPMU spec for train  https://review.openstack.org/65126915:05
*** ttsiouts has quit IRC15:05
*** ttsiouts has joined #openstack-nova15:06
mordredmriedem: done15:06
kashyapmriedem: A practical example is: the existing libvirt APIs can't answer this: Is this combination of 'IvyBridge' CPU model with 'pcid' and 'pdpe1gb' supported by the KVM+QEMU+libvirt on the host?15:07
sean-k-mooneykashyap: isnt that a defct in libvirt15:07
kashyapsean-k-mooney: Yes, it is.  That's why I asked libvirt upstream to provide the two new RFEs: https://bugzilla.redhat.com/show_bug.cgi?id=155983215:08
openstackbugzilla.redhat.com bug 1559832 in libvirt "[RFE] Fine-grained API to validate if a given CPU model and flags are supported by QEMU / KVM" [Unspecified,Closed: nextrelease] - Assigned to jdenemar15:08
sean-k-mooneyit could tell if pdpe1gb was supporte by looking the the host cpu flags15:08
kashyap(To solve the problem for Nova.)15:08
mriedemkashyap: so today operators can just populate cpu_model_extra_flags with ['pcid', 'pdpe1gb'] and we'll blindly throw those into the guest cpu config, which may or may not cause the guest to fail to launch?15:08
sean-k-mooneykashyap: yes but this is somthing that qemu should also be able to do today but it does not provde a cli to ask to question15:08
kashyapsean-k-mooney: I think we're hand-waving; if you see the upstream patch `diff` for libvirt that introduced the APIs, you'll see what is involved15:08
kashyapAnd also please see the spec I posted.  Which compares the two APIs15:08
kashyapmriedem: Yep, exactly15:09
kashyapsean-k-mooney: Here libvirt is taking advantage of the enormous work done in QEMU.  (Look up: `query-cpu-model-expansion`)15:09
sean-k-mooneymriedem: yes that why we originally had a whitelist of jsut pcid15:09
kashyapsean-k-mooney: See this blog post from the QEMU's CPU modelling infra maintainer: https://habkost.net/posts/2017/03/qemu-cpu-model-probing-story.html15:09
mriedemok, so that would be good information for the spec, i.e. today operators have to be careful about how they configure nova-compute for the libvirt driver with regard to cpu_model and cpu_model_extra_flags because the wrong combination can lead to failures to launch a guest - with this change the libvirt driver will automatically figure that out so the operator can set it and forget it15:10
kashyapmriedem: Yep, whatever it takes to make it clear.  It's also the "curse of having too much context".  I hesitate to add needless detail15:10
mriedemmordred: thanks15:10
sean-k-mooneyi dont think we should forget it15:10
sean-k-mooneyif you enable somting in the config that is invalid i would prefer if the nova compute agent failed to start15:11
kashyap(Yes, the whitelist was for stable branches)15:11
sean-k-mooneykashyap: not just for stable branches15:11
mriedemkashyap: i realize you're close to the libvirt / qemu details on this stuff, but consider your audience is not so as a nova spec reviewer i understand nova things and need to know how this translates to nova problems and how they are fixed by this spec15:11
kashyapmriedem: I go to painful lengths to be aware of that.15:12
sean-k-mooneykashyap: i reasied the problem of doing the validation on the reviews for you extra flags patches15:12
kashyapmriedem: If you closely read what I write, I make a lot of effort to write with "no assumptions", and with a full-assed beginning, middle and an end :-)15:12
kashyapsean-k-mooney: Well, I remember the change.  You're forgetting something:15:12
kashyapsean-k-mooney: Until Rocky we white-listed; after that we lifted it.15:13
sean-k-mooneykashyap: yes and i pushed back on lifting it until we have validation of the extra flags15:13
mriedemkashyap: the writing isn't the problem, i understand the words, they just don't have context for me15:13
mriedemanyway if others are cool with approving this fine15:13
mriedemi didn't -1 it15:13
kashyapmriedem: Noted, I should have also linked the relevant Nova code, from which it came from.15:13
sean-k-mooneyi was over ruled but i personally still thing we should not have lifted the whitelist untill we have a way to validate it15:13
kashyapmriedem: Yeah, noticed it.  Appreciate the restraint :-)15:13
kashyapmriedem: That spec (and the libvirt work) is derived directly from the problem Nova was facing, BTW15:14
kashyap(Anyway, you see that now.  I shold've made it clearer)15:14
kashyapsean-k-mooney: I think there we disagree.  Lifting the restrictions then made sense, and now it does.15:15
*** tbachman has quit IRC15:15
sean-k-mooneywe only lifted the restition because of all the specultive execution vulnerablitys and the fact we tought there would need to be a lot of extra cpus flags in the coming months15:16
kashyapsean-k-mooney: Recall the solid reason *why* we allowed free-form: at that time we had no damn idea what else CPU flags Intel et al will introduce15:16
dansmithsean-k-mooney: are you talking about the cpu flags thing that we added for spectre15:16
dansmith?15:16
kashyapYep15:16
dansmithsean-k-mooney: the whitelist was *only* for stable, never intended to have that in master going forward15:17
kashyapExactly.  I think sean-k-mooney got things mixed up.15:17
sean-k-mooneyno15:17
sean-k-mooneythat was the desicion we came to in the end15:17
dansmithum, what?15:18
sean-k-mooneybut i did not think we should add the feature at all without validation logic15:18
sean-k-mooneyi was ok with not having the validation logic if we had a whitelist15:18
sean-k-mooneyand i was ok with removing the whitelist due to the security concerns15:18
dansmithtbh, I don't recall you even being involved :)15:19
sean-k-mooneybut i still think we should have the validation15:19
sean-k-mooneyi was at intel a the time and was not allowed to talk publically about it much15:19
sean-k-mooneyso im not sure how much of my  comment were recored upstream and how much i said to indivigual people15:20
mriedemefried: nit and question in https://review.openstack.org/#/c/648800/615:20
* gibi only was able to read half of the specs in the etherpad during the day and has to leave now15:21
dansmithwell, anyway, the plan was to make it free-form going forward, and the compromise for stable was to add the whitelist instead of a different-for-stable config flag15:21
sean-k-mooneyya and kashyap's spec https://review.openstack.org/#/c/645814/4/specs/train/approved/cpu-selection-with-hypervisor-consideration.rst add the validation i was originally hoping for so that makes me happy :)15:22
dansmiththe only reason for the whitelist was to avoid having a different config flag for stable than master15:22
kashyapYes, what dansmith said.15:22
*** sapd1_x has joined #openstack-nova15:22
*** tbachman has joined #openstack-nova15:22
openstackgerritEric Fried proposed openstack/nova-specs master: Tools & docs for backlog & abandoned spec process  https://review.openstack.org/64880015:23
efriedmriedem: answered ^15:23
efriedmriedem: stephenfin helped out with the tox thing, so it must be right.15:23
efriedgibi: Thank you for your participation!15:24
*** sapd1_x has quit IRC15:27
*** lpetrut has quit IRC15:29
sean-k-mooneykashyap: ok but my request for validating the feature is there in https://review.openstack.org/#/c/534384/5/nova/conf/libvirt.py@538 anyway im almost through your spec which seams to provide it anyway.15:31
mriedemefried: ok final question https://review.openstack.org/#/c/648800/715:31
*** ivve has quit IRC15:32
kashyapsean-k-mooney: Nod; I recall seeing the comment15:33
*** awalende has joined #openstack-nova15:33
*** gyee has joined #openstack-nova15:35
*** udesale has quit IRC15:37
*** awalende has quit IRC15:37
*** dave-mccowan has joined #openstack-nova15:40
efriedmriedem: responded15:41
efriedmriedem: Believe me, I would have preferred to put the glob in this change instead of individually in the four on top :(15:41
*** tbachman has quit IRC15:41
efriedI think gerrit will at least be smart enough not to generate a merge conflict on the three remaining when the first one merges...15:42
*** luksky has quit IRC15:42
*** tbachman has joined #openstack-nova15:44
efrieddakshina-ilangov: A couple of things about https://review.openstack.org/#/c/651130/ just procedurally:15:46
efried1) Please wrap the body of the commit message at 72c15:46
efried2) You can build locally by running `tox -e docs` to resolve formatting issues15:46
*** ttsiouts has quit IRC15:56
openstackgerritStephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec  https://review.openstack.org/63873415:56
*** ttsiouts has joined #openstack-nova15:57
*** jistr|call is now known as jistr16:00
*** ttsiouts has quit IRC16:01
*** dakshina-ilangov has quit IRC16:04
openstackgerritFrançois Palin proposed openstack/nova master: nova diagnostics command is not working with all interfaces  https://review.openstack.org/64812316:08
*** priteau has joined #openstack-nova16:13
stephenfinkaboom16:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove cells v1 jobs  https://review.openstack.org/65128916:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'nova-cells' service  https://review.openstack.org/65129016:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove '/os-cells' REST APIs  https://review.openstack.org/65129116:15
openstackgerritStephen Finucane proposed openstack/nova master: Stop handling cells v1 in '/os-hypervisors' API  https://review.openstack.org/65129216:15
openstackgerritStephen Finucane proposed openstack/nova master: Stop handling cells v1 in '/os-servers' API  https://review.openstack.org/65129316:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'nova-manage cell' commands  https://review.openstack.org/65129416:15
openstackgerritStephen Finucane proposed openstack/nova master: Stop handling cells v1 for console authentication  https://review.openstack.org/65129516:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove old-style cell v1 instance listing  https://review.openstack.org/65129616:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'bdm_(update_or_create|destroy)_at_top'  https://review.openstack.org/65129716:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'instance_fault_create_at_top'  https://review.openstack.org/65129816:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'instance_info_cache_update_at_top'  https://review.openstack.org/65129916:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'get_keypair_at_top'  https://review.openstack.org/65130016:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'instance_update_at_top', 'instance_destroy_at_top'  https://review.openstack.org/65130116:15
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'instance_update_from_api'  https://review.openstack.org/65130216:16
openstackgerritStephen Finucane proposed openstack/nova master: Stop handling 'update_cells' on 'BandwidthUsage.create'  https://review.openstack.org/65130316:16
openstackgerritStephen Finucane proposed openstack/nova master: Stop handling cells v1 for instance naming  https://review.openstack.org/65130416:16
openstackgerritStephen Finucane proposed openstack/nova master: Stop handling 'cell_name' field on Instance.save()  https://review.openstack.org/65130516:16
openstackgerritStephen Finucane proposed openstack/nova master: Remove cells code  https://review.openstack.org/65130616:16
sean-k-mooneycells v1 removal16:16
stephenfinI _think_ all but the last two or three should be passing unit test, functional tests and pep816:16
* stephenfin crosses fingers16:16
stephenfinsean-k-mooney: yuuup16:16
sean-k-mooneywell the gate is going to be busy for a while16:16
stephenfinFirst time in days that my laptop hasn't sounded like a rocket16:17
mriedemstephenfin: are you going to throw that blueprint in the meeting agenda for thursday since it's a specless blueprint?16:17
stephenfinmriedem: Good call. Sure16:17
gmannmriedem: I would like to keep only first 3 fixes in this spec,  hoping that will not be big for review/doc ? - https://review.openstack.org/#/c/603969/916:17
mriedembecause i may or may not have several new edge use cases and features for cells v1 and will block it's removal16:18
gmannmriedem: success  code change is something need more audit and can be done later ?16:18
mriedemgmann: those first 3 are probably ok and straight-forward enough16:19
gmannok. let me update the spec.16:19
*** phasespace has joined #openstack-nova16:25
openstackgerritSylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs  https://review.openstack.org/65096316:25
bauzasstephenfin: thanks for reviewing https://review.openstack.org/#/c/650963/, just wrote PS216:25
*** tjgresha has joined #openstack-nova16:26
tssuryamordred, mriedem, dansmith: after the back and forths on changing the type of the "locked" response key since all of you are for the seperate key style and no change on type I will just update the spec then to that approach.16:33
dansmithtssurya: thanks16:34
tssuryaseparate*16:34
mordred++16:34
dansmithI was shocked to have mordred come in and agree with me16:34
dansmithhe might not have realized what he was doing though16:34
dansmithstephenfin: melwitt bauzas mriedem: I didn't see any discussion about how stephenfin only created five placeholders for the main db this time, but I do think that's probably more than enough and would be good for the future16:39
bauzasyeah, I just feel 5 is enough given the history16:39
stephenfindansmith: I _think_ I called it out in the commit message or a comment, so I figured everyone was ok with that16:39
dansmithstephenfin: I didn't see it anywhere16:40
stephenfin(did it because you mentioned that we'd never used them anyway)16:40
mordreddansmith: wait. I change my mind. whatever the opposite things is please16:40
dansmithmordred: :)16:40
stephenfindansmith: Yeah, it wasn't as obvious as it should have been but it's there alright https://review.openstack.org/#/c/650964/1/nova/tests/unit/db/test_migrations.py@18316:41
dansmithack, okay16:41
* stephenfin 's head hurts from spec reviews, -> home16:41
mriedemhe put it in a comment16:44
mriedemoh yeah i'm late16:44
dansmithI didn't read that deep since it was already merged, just saw the fewer file count16:44
*** dpawlik has quit IRC16:51
*** derekh has quit IRC17:00
*** psachin has quit IRC17:00
*** dtantsur is now known as dtantsur|afk17:03
*** priteau has quit IRC17:04
gmanndansmith: mriedem mordred can we remove 'locked' field in favor of 'locked_by' in https://review.openstack.org/#/c/638629/9/specs/train/approved/add-locked-reason.rst@19817:06
dansmithI'd rather we didn't17:06
mordredgmann: it would be nicer to not remove the field17:06
gmannit will be change for old user so no strong opinion just a thought.17:06
dansmithit's just senseless change for no real gain17:06
gmannyeah17:06
mriedempretty sure that was discussed in some of the earlier patch sets17:07
gmannok.17:07
bauzasstephenfin: I'm a terrible man, I left you a -1 on https://review.openstack.org/#/c/555081 after you left17:09
*** tjgresha has quit IRC17:10
bauzasbut I feel it's worth discussing on the upgrade path17:10
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup  https://review.openstack.org/60396917:10
bauzasI'm in favor of just saying "heh dude, migrate your workloads first before touching anything or your compute will blow up"17:10
gmannmriedem: mordred updated the API cleanup spec with only 3 cleanups to target.  https://review.openstack.org/60396917:10
dansmithbauzas: um, really?17:11
dansmithbauzas: you want cern to have to migrate all their workloads before/during an upgrade?17:11
bauzasdansmith: no, that's not what I meant17:11
bauzasdansmith: I meant, before changing the opts17:12
bauzasif you upgrade and just keep the same conf, you're not impacted17:12
bauzasactually, I left another comment saying this17:12
bauzasie. keep existing behaviour in Train exactly like in Stein if untouched17:13
dansmithokay let me re-read17:13
bauzasdansmith: context being https://review.openstack.org/#/c/555081/2217:13
dansmithright I know :)17:13
bauzashttps://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@171 is the existing backwards compat concern I have => don't change anything17:14
mriedemtssurya: gmann: i left some comments on the locked reason spec regarding filtering and sorting, but i'm not sure why locked is not a valid sort/filter parameter but locked_by is - even though we dont currently expose the latter17:14
mordredgmann: all of those fields with OS-EXT prefixes are readonly aren't they?17:14
bauzashttps://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@181 is the "what happens when you start playing with those new opts"17:14
tssuryamriedem: I was just about to push :)17:15
dansmithbauzas: okay, so what happens if you do make those changes on a compute node with instances?17:15
bauzasoh man, I really thought the locked reason spec was not controversial :)17:15
tssuryaoh had just added filtering based on the new keys will be allowed17:15
mordredgmann: in any case - we expose all of those without the prefix in sdk already - so I'm definitely in favor of that cleanup :)17:15
mriedemtssurya: you can't filter on something that's stored in system_metadata17:16
dansmithbauzas: as long as the same config means you don't have to move stuff that's okay, I thought you were kindof implying that they would have to move everything at some point though17:16
bauzasdansmith: that's my point, in the spec, we say we reshape17:16
bauzaswhen we start using those opts17:16
tssuryabauzas: I thought so too! (when I initially proposed it)17:16
mordred(although I think I need to add a way to express inside of sdk "this property comes from whichever of OS-EXT-AZ:availability_zone or availability_zone exists"17:16
bauzasdansmith: nope, nope, keep same things in Train if config unchanged17:16
dansmithbauzas: I would expect someone like CERN to really care about enabling this sort of thing and requiring everyone to move many gigs of data around just so we don't have to reshape is kinda icky17:16
dansmithI mean, really icky17:17
bauzasdansmith: I totally agree17:17
tssuryamriedem: oh yea forgot ! I guess we discussed this too earlier in the spec when we were deciding where to put it17:17
mriedemmordred: not necessarily, OS-DCF:diskConfig is on server create17:17
gmannmriedem:   they are all in response so did not get readonly thing completely17:17
bauzasdansmith: that's why I'm in favor of a full service stop if operators start playing with new config opts in Train and have existing instances17:17
mordredmriedem: ah - so it is. ok - that one will take a little extra effort - but shouldn't be too bad17:17
mriedemgmann: OS-DCF:diskConfig is in server create and resize requests17:18
mordredconsuming whichever field name happens to be in the response is easy - knowing which field name one is supposed to send to the api is more effort17:18
mordredbut still doable and fine17:18
mriedemi don't know that gmann was thinking about request params, and i just thought of OS-DCF:diskConfig since you saked17:19
mriedem*asked17:19
mriedemthere could be others, it's a crusty api17:19
gmannok, user data is one case?17:19
dansmithbauzas: but I'm saying I think that we should be able to provide support for them stopping a compute, tweaking the params to enable, and then restart... with instances.17:19
mriedemuser_data is not prefixed in the create request17:19
mordredmriedem: I was mostly looking at the list in https://review.openstack.org/#/c/603969/10/specs/train/approved/api-consistency-cleanup.rst17:19
bauzasdansmith: with a reshape ?17:19
gmannOS-DCF:diskConfig  will not be changed right17:19
bauzasdansmith: sorry if I'm not getting you17:19
dansmithbauzas: we can abort on startup if they have specified something that can't be reshaped, requiring them to move some stuff off before doing it, but requiring clearing every single compute node (over time) to turn that on really sucks17:20
bauzasdansmith: okay so you're in favor of some automation17:20
bauzaslemme reconsider that17:20
mordreddansmith: just adopt cloud native design principles and stop writing files to disk. solves all your problems17:20
dansmithmordred: heh17:21
gmannmriedem: tssurya locked_by in valid sort/filter list was mistake. we can improve that in tssurya spec i think.17:21
mriedemmistake because it's a field we don't even expose today?17:22
tssuryagmann, mriedem: I will add locked" as a sort/filter key17:22
mriedemi know at one point there was a comment in the code near these fields that said "don't use locked anymore" becaues locked_by implied locked17:22
tssuryabut as for the existing "locked_by" key in the whitelist, isn't that just a refactor of code ? since we don't expose it anyways ?17:22
gmannmriedem: yes, we did not expose that and had in valid sort/fitler17:23
mriedemtssurya: refactor of code?17:23
gmanni tried to check the reason in original change but did not find any rational to add in whitelist17:23
mriedemtssurya: as i mentioned in the spec, supporting filtering on locked_by could get weird,17:23
tssuryamriedem: no I don't want to support locked_by based filtering as well17:24
tssuryaits useless IMO17:24
mriedembecaues if we expose locked_by=admin or other, but only store admin or owner, then filtering on locked_by=other means we have to do something like "select * from instances where locked_by!='admin'"17:24
dansmithfiltering in the api on a non-db field isn't *super* terrible, but sorting is17:24
gmannthis one  - https://review.openstack.org/#/c/408571/17:24
bauzasdansmith: just to make sure https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@725 requires a reshape, right?17:24
mriedemdansmith: i don't think sorting is a problem really here17:25
bauzasie. libvirt sees the options be set, raises a ReshapeNeeded, gets the inventories and allocations, move them17:25
mriedemfiltering would have to be special cased though, and locked_by is in the db17:25
dansmithbauzas: properly representing allocations of dedicated cpus as PCPU right? Not even migration will fix those instances, so I would think reshape is the *only* way to fix that, no?17:26
mriedemmy pizza is getting dangerously cold17:27
*** mriedem is now known as mriedem_away17:27
dansmithbauzas: unless you depend on scheduler/conductor to generate a new allocation for a properly hierarchical instance I guess, but.. that's just really super expensive when all you want to do is move some numbers around17:27
bauzasdansmith: well, in a world before pcpu_shared_set, all instances are seen as using shared set of CPUs, so they need to be VCPU anyway, but the problem is that if we reserve, say CPU1, then we need to arbitratly assign instances using this CPU1 as PCPU17:27
dansmithmriedem_away: I know we can filter on locked_by in the db, but I'm saying if we allow filtering on locked and then drop locked in the future, we can continue honoring that behavior from other fields17:28
bauzasdansmith: but then there is an allocation ratio problem, since we don't want to oversubscribe on PCPU17:28
dansmithbauzas: but L725 is talking about instances that already have dedicated cpus, but represented as VCPU right?17:28
cdentefried: I'm moving on to the cross project nova+placement etherpad for my pre-ptg emails. a) cool with that? b) okay with the process I've been following c) anything especially I should or should not skip?17:28
bauzasdansmith: yup, but the above example is still valid, nope?17:29
bauzasit's just undocumented in the spec17:29
* dansmith is confused17:29
bauzasthat's what I tried to address in https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@18117:29
bauzasactually, my wife yells at me because I need to go eating melted cheese17:30
bauzasI need to disappear17:30
bauzashttps://en.wikipedia.org/wiki/Vacherin#Mont_d'Or17:31
gmannmriedem_away: mordred let me check those fields from request point of view.17:32
sean-k-mooneybauzas: stephenfin can ye review https://review.openstack.org/#/c/649882/ its related to both the cpus in placemnt spec and numa in placement17:33
bauzasdansmith: left another comment trying to describe my concerns in https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@18117:37
bauzashopefully it will help17:37
bauzasnow I need to bail out17:37
dansmithbauzas: I just commented summarizing my view17:37
dansmithmaybe that will help17:37
dansmithgo eat cheese17:37
*** tjgresha has joined #openstack-nova17:38
bauzasdansmith: okay, i'll join later17:38
*** gmann is now known as gmann_afk17:40
efriedcdent: a) Sure, if you're done with nova reviews :P  b) Yes, me likey. (Note that I am reading all of them, but only responding when I have something to say; I'm not sure there's positive value in an empty ack.);  c) other than things you already mentioned (perhaps those should be re/moved from the main part of the etherpad?)17:41
jmlowecdent: Got a quick question about placement and vgpus17:43
efriedcdent: also on a) and b), I am likely to hold off on any further responses until tomorrow. Trying to focus solely on nova spec reviews today (though the gods are conspiring to make that challenging).17:43
*** ralonsoh has quit IRC17:44
cdenta) I clicked on every link on the spec etherpad this morning and left reviews where I felt comfortable. sometimes I did not because my reaction was "oh look, yet more complexity for the five people who care" and didn't think that was too helpful, so moved on to something else, b) cool, c) I'm trying to make sure the etherpad exposes what has thread17:44
cdentjmlowe: hola17:44
cdentjmlowe: I can try to help, but the specifics of how the vgpus are being managed is not much in my wheelhouse17:45
*** mriedem_away is now known as mriedem17:46
mriedemtssurya: so maybe a question that you don't want to hear right now, but do we really need to expose that locked_by field? it seems to be causing a lot more unnecessary churn on this spec than is needed17:47
mriedemif the point of the spec is just expose a reason field, can we just....do that?17:47
*** wolverineav has joined #openstack-nova17:48
jmlowecdent: So we got 6 nodes with 4 nvidia v100's each for a total of 24, the thing that's confusing me is that in the docs the example is "openstack flavor set vgpu_1 --property "resources:VGPU=1"", I can slice these 8 ways, how do I manipulate the resources in placement so that I have 4*8 vgpus? Or do I have a GCE when it comes to resources, filter scheduler, and placement?17:48
* cdent is digesting17:50
jmloweseems like a major omission, how do I tell placement how many of some arbitrary thing I have?17:50
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862917:51
cdentjmlowe: what release are you on these days?17:51
jmloweRocky17:52
sean-k-mooneyjmlowe: bauzas will be able to answer but you should not need too17:52
tssuryamriedem: just saw your comment here :/17:52
mriedemi left them on the spec as well, you can answer whenever17:52
*** wolverineav has quit IRC17:52
tssuryahmm, ok if we are going to expose "locked" after all then locked_by is not needed17:52
*** wolverineav has joined #openstack-nova17:53
sean-k-mooneyjmlowe: there are some limitation in what we currently supprot but as of stien we shoudl now have a nested resoucp provider per phyical gpu17:53
*** tjgresha has quit IRC17:53
sean-k-mooneyeach phyical gpu will have an inventory of 8 vGPU reources17:53
jmloweany chance this is explained in the Stein admin guide?17:53
cdentjmlowe: the issue you've got is that what's possible in Stein is a lot different from what's possible in Rocky17:54
sean-k-mooneyjmlowe: in rocky i know we did not support multiple vgpus type on the same host but we might have supported multipel pysical gpus17:54
jmlowe*looking ahead to stein admin guide17:54
sean-k-mooneyjmlowe: i think bauzas wrote something up yes but not sure if its in the admin guide17:55
*** sridharg has quit IRC17:55
*** davidsha_ has quit IRC17:55
mriedemtssurya: we already expose locked :)17:55
jmloweok, this is starting to make more sense now that I understand the limitations of <= Rocky17:56
mriedemhttps://docs.openstack.org/nova/rocky/admin/virtual-gpu.html17:56
mriedemthat's the vgpu admin guide for rocky17:56
mriedemhttps://docs.openstack.org/nova/stein/admin/virtual-gpu.html#checking-allocations-and-inventories-for-virtual-gpus is new content for stein17:57
mriedemthe placement CLI examples in there may or may not be useful to you in rocky17:57
sean-k-mooneyya so in rocky we supporte 1 gpu type per node but i belive we had supported muplip phyical gpus that were reported in 1 inventory on the compute node RP17:57
mriedemthe main difference is in stein there are nested providers for VGPU inventory and allocations17:57
sean-k-mooneyand in stien we reshap them into child resouce providers17:58
cdentjmlowe: this may be informative: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#checking-allocations-and-inventories-for-virtual-gpus17:58
cdentoh, sorry, mriedem just did that17:58
cdentwas off looking.17:58
* mriedem has it memorized17:59
* cdent is being trained to just wait for mriedem to find everything17:59
cdentIs dinner time18:00
* cdent waves18:00
*** cdent has quit IRC18:00
*** sidx64 has joined #openstack-nova18:00
tssuryaefried: wait wait I am updating that spec to remove that part which you just commented18:02
efriedtssurya: Okay. Don't worry, I wasn't merging it :)18:02
efriedyou're going to just not display locked_by at all?18:02
efriedSigh, I guess that's one way to skin this cat.18:03
efriedAnd you would know better than I whether a user would want to report on "locked by me" and/or "locked by not-me".18:03
tssuryaefried: yea18:03
tssuryaI am going to kick locked_by18:04
*** ricolin has quit IRC18:04
tssuryathat's causing all the confusion18:04
efriedAnd I guess that could be added later, though it would seem like a lot of work to spin a whole new blueprint/spec/microversion just for that.18:04
tssuryaefried: yea that's why I had intially added it here18:04
tssuryabut I hope nobody would want locked_by ?18:04
efriedthat's the thing18:05
tssuryawhen the user tries to unlock they would know if it was "locked by me" or not18:05
efriedlike I'm doing maintenance, so I lock a bunch of things, and then my maint is done, so I want to unlock the things. But I forgot to keep track of the ones I locked. So I want a report that says "hey, what did I lock?"18:05
dansmithI was told that the way to tell if it's locked by me is to unlock it :P18:06
efriedyeah. I could script to unlock "everything" and tolerate the failures ^18:06
dansmithwhich seems silly to me18:06
efriedthat's pretty ugly18:06
*** sidx64_ has joined #openstack-nova18:06
dansmithbecause checking policy of an unlock operation during get is not okay for some reason18:06
*** sidx64 has quit IRC18:06
efriedbecuase the policy is conditional on the owner of the lock?18:07
efrieda thing that can't be determined at policy enforcement time?18:07
dansmithI dunno18:07
dansmithwhat I want is a boolean that tells me "can I unlock this thing?"18:07
efriedlocked_by == 'owner'18:07
efriedtssurya: Okay, so I'm with dansmith on this. Who's the dissenter? mriedem?18:08
dansmithbut if I'm an admin, I can unlock it too18:08
dansmithor if the policy is such that I can unlock..18:08
dansmithefried: just to be clear, I'm fine with not exposing locked_by18:08
mriedemefried: locked_by won't tell you "hey, what did I lock?" anyway18:08
efriedOkay,18:08
efriedcan_I_unlock = am_I_admin or locked_by == 'owner'18:08
mriedemand owner = the instance is in a project that i'm in18:09
dansmithnot sure that's enough18:09
mriedemi think...18:09
dansmithcan't I write complex policy to allow a role that can unlock things for other projects?18:09
dansmithregardless, I'd really suggest we not get back into this, remove locked_by and let tssurya proceed18:10
tssuryadansmith: thanks :)18:10
tssuryaefried you okay with that ?18:10
efriedsure18:10
mriedemi also really don't want to think about locked_by anymore, so if the goal is add a reason field, let's do that - making locked_by not suck is a whole other can of worms18:11
mriedemand likely a separate spec18:11
efriedI can get on board with that ^18:11
efriedI had actually drafted a comment that read a lot like that18:11
tssuryaok thanks everyone I am deleting locked_by from my memory18:11
efriedtssurya: you can't delete it from memory.18:11
efriedyou should put something in Alternatives so we remember we had this conversation.18:12
mriedemnot persistent memory anyway https://review.openstack.org/#/c/601596/18:12
mriedemhi-o!!!!18:12
* efried high-five-sikes mriedem18:12
efriedtssurya: ...even if it's just a link to the eavesdrop of this conversation18:12
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862918:13
mriedemi feel like at this point in my day my time would be better served raking up dead grass outside since it's supposed to dump a foot a snow on us tomorrow18:14
mriedem*of snow18:14
*** gmann_afk is now known as gmann18:21
*** rpittau is now known as rpittau|afk18:21
*** luksky has joined #openstack-nova18:22
gmanntssurya: mriedem efried dansmith can we remove the locked_by from valid sort/filter key also as that is not going to be exposed anyway.18:24
*** lpetrut has joined #openstack-nova18:25
efriedgmann: If it does nothing right now? Then sure, why don't we do that in a totally unrelated patch?18:26
gmannefried: that need microversion bump so doing in unrelated patch need another spec and version bump18:27
efriedgmann: So it *does* do something right now?18:27
efriedIt actually works, you just don't see the locked_by field in your result?18:28
efriedor it's ignored, but removing it will cause a 400?18:28
dansmithanybody want to blow their brains out when I'm done with mine?18:28
*** lpetrut has quit IRC18:29
gmannefried: yeah it does not show locked_by in results so user will just assume it worked well but no confirmation. in code we do consider that.18:30
efriedthen why remove it?18:30
gmannthere is no way for user to know what is valid value of locked_by as nova does not expose that at all18:30
efriedrather than put it off until later and fix it properly18:30
gansoHi efried. Sorry to interrupt. When you have some time, could you please review https://review.openstack.org/#/c/650437/ and https://review.openstack.org/#/c/649421/  ? Thanks in advance18:31
efriedganso: Is tomorrow soon enough? I'd like to focus on specs as much as possible today.18:31
gansoefried: sure, thank you!18:32
gmannok, if we do something with locked_by later then only fix sort/filter too / that is ok for me.18:32
efriedganso: Oh, those are stein. I'm not stable, so I can't really help you :)18:32
efriedgmann: Okay, I think that's the plan.18:32
gansoefried: oh, sorry... I'll look for the stable maintainers18:32
gmann+118:32
efriedgmann: Current bp is going to add sorting/filtering by the locked bool.18:33
efriediiuc18:33
efriedbut ignore locked_by entirely - not fix it or remove it.18:33
mriedemganso: https://review.openstack.org/#/admin/groups/540,members18:34
gmannefried: you mean current spec will start ignoring 'locked_by' from sort/filter ?18:34
mriedemganso: but also, those can't merge yet anyway b/c we haven't GA'ed stien18:34
mriedem*stein18:34
gansomriedem: oh right! release is friday, correct?18:35
gmanni feel leave it as it is currently.18:35
mriedemhence my -W on the bottom patch18:35
mriedemganso: tomorrow i think18:35
efriedgmann: No, sorry, I mean the current spec will do nothing to change locked_by in any way.18:35
mriedemdansmith: grab a rake18:35
gmannefried: +118:35
* efried waits to see how dansmith plans to blow his brains out with a rake.18:35
*** tjgresha has joined #openstack-nova18:36
*** betherly has joined #openstack-nova18:38
*** eharney has quit IRC18:42
*** betherly has quit IRC18:43
*** IvensZambrano has quit IRC18:43
*** wolverineav has quit IRC18:46
openstackgerritLee Yarwood proposed openstack/nova master: Block swap volume on volumes with >1 rw attachment  https://review.openstack.org/57279018:46
openstackgerritLee Yarwood proposed openstack/nova master: Keep attach_mode as top-level field in _translate_attachment_ref  https://review.openstack.org/57441318:46
*** wolverineav has joined #openstack-nova18:47
lyarwoodmriedem: ^ hope you don't mind, this came up downstream last week, finally getting back around to it now and noticed some whitespace.18:47
*** wolverineav has quit IRC18:52
*** betherly has joined #openstack-nova18:59
*** betherly has quit IRC19:04
*** ociuhandu has joined #openstack-nova19:04
*** bbowen_ has joined #openstack-nova19:06
*** bbowen has quit IRC19:09
*** tbachman has quit IRC19:15
*** whoami-rajat has quit IRC19:17
*** betherly has joined #openstack-nova19:20
*** wolverineav has joined #openstack-nova19:23
*** wolverineav has quit IRC19:23
*** wolverineav has joined #openstack-nova19:24
*** betherly has quit IRC19:25
*** sidx64_ has quit IRC19:27
*** efried is now known as efried_afk19:30
tssuryamriedem, dansmith: thanks for reviewing https://review.openstack.org/#/c/636132/ , sorry didn't get time to respond, will go through it tomorrow.19:34
dansmithtssurya: hopefully we can make this one every bit as painful as the locked_by one!19:35
dansmith(not)19:35
*** boxiang has quit IRC19:37
*** boxiang has joined #openstack-nova19:37
*** eharney has joined #openstack-nova19:38
*** tssurya has quit IRC19:39
*** dakshina-ilangov has joined #openstack-nova19:40
*** betherly has joined #openstack-nova19:41
mriedemlyarwood: 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:41
*** bbowen__ has joined #openstack-nova19:43
lyarwoodmriedem: ack thanks will do19:44
*** awaugama has quit IRC19:44
mriedemlyarwood: btw i was told you own this now https://review.openstack.org/#/c/551349/19:44
*** betherly has quit IRC19:45
lyarwoodmriedem: yeah, I've just not found my way back to it since the last PS19:46
*** bbowen_ has quit IRC19:46
mriedemlet your heart guide you young lee19:46
lyarwoodmriedem: I'll queue it up for the morning, thanks for the review!19:47
*** betherly has joined #openstack-nova20:01
*** sean-k-mooney has quit IRC20:05
*** betherly has quit IRC20:06
*** bbowen__ has quit IRC20:08
*** sean-k-mooney has joined #openstack-nova20:09
*** jackding has quit IRC20:11
*** jackding has joined #openstack-nova20:12
*** amodi has quit IRC20:15
*** betherly has joined #openstack-nova20:22
mriedemso we agree we're not going to sort/filter on locked_reason right20:24
mriedem?20:24
*** betherly has quit IRC20:26
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862920:27
*** wolverineav has quit IRC20:27
gmannmriedem: right. filter/sort by 'locked' only20:28
mriedemefried_afk: well, got one spec approved today20:29
mriedemwho has the champagne? is dansmith still alive?20:29
dansmithheh20:31
*** pcaruana has quit IRC20:31
*** wolverineav has joined #openstack-nova20:32
*** pcaruana has joined #openstack-nova20:33
*** pcaruana has quit IRC20:36
*** wolverineav has quit IRC20:37
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup  https://review.openstack.org/60396920:38
gmannmriedem: updated the readonly info for OS_EXt prefix fields  ^^. OS-DCF:diskConfig i propose to change in request also.20:38
gmannchecked all the extensions fields and listed the one with prefix20:38
*** pcaruana has joined #openstack-nova20:39
*** pcaruana has quit IRC20:47
openstackgerritMerged openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862920:48
*** wolverineav has joined #openstack-nova20:50
*** ttsiouts has joined #openstack-nova20:55
*** wolverineav has quit IRC20:57
*** tbachman has joined #openstack-nova20:58
*** wolverineav has joined #openstack-nova20:59
*** wolverineav has quit IRC21:00
*** wolverineav has joined #openstack-nova21:00
*** betherly has joined #openstack-nova21:03
*** betherly has quit IRC21:08
*** bbowen__ has joined #openstack-nova21:09
*** wolverineav has quit IRC21:15
*** wolverineav has joined #openstack-nova21:16
*** eharney has quit IRC21:19
*** wolverineav has quit IRC21:21
*** wolverineav has joined #openstack-nova21:23
*** efried_afk is now known as efried21:25
*** igordc has quit IRC21:25
*** wolverineav has quit IRC21:27
efriedmriedem: \o/ but a lot got done today.21:27
efriedand especially leading up to today, with people fleshing their specs.21:27
*** wolverineav has joined #openstack-nova21:28
*** wolverineav has quit IRC21:28
*** wolverin_ has joined #openstack-nova21:29
*** wolverin_ has quit IRC21:31
*** wolverineav has joined #openstack-nova21:33
*** wolverineav has quit IRC21:38
*** mchlumsky has quit IRC21:44
*** betherly has joined #openstack-nova21:44
*** betherly has quit IRC21:49
*** tesseract has quit IRC21:50
*** luksky has quit IRC21:50
*** wolverineav has joined #openstack-nova21:58
*** awalende has joined #openstack-nova22:00
*** slaweq has quit IRC22:01
*** awalende has quit IRC22:04
*** hongbin has joined #openstack-nova22:13
*** slaweq has joined #openstack-nova22:14
*** ttsiouts has quit IRC22:16
*** ttsiouts has joined #openstack-nova22:17
*** slaweq has quit IRC22:18
*** ttsiouts has quit IRC22:21
*** rcernin has joined #openstack-nova22:28
*** jamesdenton has joined #openstack-nova22:32
mordredefried: heh libvirt gorp22:37
openstackgerritDakshina Ilangovan proposed openstack/nova-specs master: Nova LLC allocation - RMD plugin for RDT CAT  https://review.openstack.org/65123322:38
*** tkajinam has joined #openstack-nova22:53
*** betherly has joined #openstack-nova22:57
*** betherly has quit IRC23:02
*** betherly has joined #openstack-nova23:18
*** betherly has quit IRC23:22
alex_xumriedem: hah, hope that is cold medicine :)23:31
*** wolverineav has quit IRC23:31
*** mlavalle has quit IRC23:32
*** wolverineav has joined #openstack-nova23:33
*** tosky has quit IRC23:36
*** betherly has joined #openstack-nova23:38
*** wolverineav has quit IRC23:41
*** betherly has quit IRC23:44
*** slaweq has joined #openstack-nova23:48
*** hongbin has quit IRC23:48
*** dklyle has quit IRC23:52
*** slaweq has quit IRC23:52
*** betherly has joined #openstack-nova23:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!