Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-09
11:02:06 kashyap Nod
11:03:26 sean-k-mooney kashyap: by the way cpu_model_list = Conroe,Penryn,Nehalem,Westmere,SandyBridge,IvyBridge,Haswell,Broadwell,Skylake-Client,Skylake-Server
11:03:42 sean-k-mooney i assume that would prefer Conroe and proceed left to right
11:04:58 openstackgerrit Dakshina Ilangovan proposed openstack/nova-specs master: Nova local resource management that uses RMD https://review.openstack.org/651130
11:05:07 sean-k-mooney in other words the operator is enabling the older cpu models first thereby ensuring the maxium compatiblity
11:05:30 kashyap sean-k-mooney: This whole idea of "CPUs must be oredered from least featureful to most" is flaky to me.
11:05:50 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:06:03 sean-k-mooney i think it will work fine
11:06:10 kashyap sean-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:14 sean-k-mooney we have prescedent for this already in neutron
11:06:51 sean-k-mooney it is more tedious but i doubt may people would list all of them
11:07:10 sean-k-mooney typically datacenters have only a handful of generations deployed concurrently
11:07:28 sean-k-mooney so i woudl expect the list to contain 2-3 in general
11:08:17 sean-k-mooney there is no point in listing a generation older then any of your servers afterall
11:09:21 kashyap Hmm, okay, that's somewhat palatable
11:09:24 sean-k-mooney so somthign like cpu_model_list = nehalam,ivybridge,skylake-server woudl be more typical
11:25:57 kashyap Right; but who knows
11:34:17 kashyap sean-k-mooney: Thanks for the comments
11:34:39 kashyap sean-k-mooney: It seems like I have suddenly "inherited" this spec, as the original proposer for Stein is nowhere to be seen.
11:37:33 sean-k-mooney no worries. i need to write one sepc and then start makeing my way through the spec review queue
11:37:49 kashyap The more I think about this spec, the more questions arise.
11:38:08 kashyap (And yes, I'll move the rationale from commit message to the spec itself.)
11:39:24 sean-k-mooney i 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 required
11:39:57 sean-k-mooney that spec predated placement so i think i also had a new schduler filter to do the compatiblity check
11:41:05 sean-k-mooney telcos have wanted somthign like this for a long time but its a blance between cloudines and hardware defined software
11:42:31 sean-k-mooney in this iteration the use of traits to exrpess the workload requirements is a nice abstration
11:45:37 cdent jaypipes++
11:46:25 jaypipes cdent: ?
11:46:30 cdent rsd spec
11:46:32 jaypipes ah
11:46:44 jaypipes just starting off spec review day...
11:47:39 kashyap sean-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:41 cdent keep rolling like that and it should be a fine day
11:47:55 kashyap sean-k-mooney: You can trivially see what flags QEMU binary supports -- surely you that
11:48:15 kashyap a/"QEMU binary"/"a given QEMU binary on the host"/
11:48:22 sean-k-mooney jaypipes: 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 disavantages
11:49:51 sean-k-mooney jaypipes: 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 questionable
11:53:28 jaypipes sean-k-mooney: so square peg, round hole it into Nova and that problem will go away? :)
11:53:31 sean-k-mooney jaypipes: 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 it
11:53:52 jaypipes sean-k-mooney: that is precisely why I believe it needs to be outside of Nova.
11:54:09 sean-k-mooney jaypipes: do you belive we shoudl delete the ironic driver?
11:54:17 jaypipes sean-k-mooney: no.
11:54:21 sean-k-mooney the integration will be almost identical
11:54:43 jaypipes sean-k-mooney: no it won't.
11:55:18 jaypipes specifically, having to create flavors on the fly
11:55:23 sean-k-mooney well i spend a year modeling it on how ironic worked with minor tweeks
11:55:29 sean-k-mooney jaypipes: that is not required
11:55:42 sean-k-mooney that was a suggesting to make testing eaier
11:56:05 sean-k-mooney the flavor it create just contain the reouces request for the custom_resouce class
11:56:06 jaypipes sean-k-mooney: I just don't think it's a good idea, sorry.
11:57:32 sean-k-mooney ok 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 it
11:57:44 sean-k-mooney you werent at teh vancour summit
11:57:55 sean-k-mooney but i was pretty sure i ran this by you at some point
11:59:30 kashyap gibi: 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.rst
12:01:21 jaypipes sean-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:23 jaypipes :)
12:01:40 jaypipes and you were working for Intel :)
12:02:39 sean-k-mooney :) ok yes but i guess we have always dissagreed then we never tought vlance was a viable approch in my team
12:03:01 gibi kashyap: ack. There is too many specs :)
12:03:30 sean-k-mooney it lost the cloud abstration meaning existing workloads/workflows needed to be modifyed to know what rsd was
12:07:25 jaypipes sean-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:08:06 jaypipes sean-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:34 jaypipes sean-k-mooney: it's hardware, plain and simple. It's not the next Kubernetes abstraction for a new type of workload.
12:09:03 sean-k-mooney yes i agree which is why i think openstacks apis need to be the abstration
12:09:11 jaypipes sean-k-mooney: we will just have to agree to disagree on this topic :)
12:09:20 sean-k-mooney i think of it as a bearmental hypervior
12:09:34 sean-k-mooney like ironic
12:13:35 kashyap gibi: Hehe, sorry. Yeah, context overload; completely understand it.
12:14:01 kashyap gibi: Take a look at it, on a non-spec day; I'll assume everyone is maxed out today
12:14:04 gibi kashyap: I kept that spec open, but I move by the etherpad order https://etherpad.openstack.org/p/nova-spec-review-day
12:14:25 kashyap (And looking at too many specs parallely will only splinter the attention to hell and back, which is costly.)
12:18:35 jaypipes sean-k-mooney: "bearmental hypervior" <-- nice.
12:19:52 kashyap Folks: 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:21:14 sean-k-mooney :)
12:22:30 openstackgerrit Merged openstack/nova master: Improve test coverage of nova.privsep.path. https://review.openstack.org/648601
12:22:38 openstackgerrit Merged openstack/nova master: Improve test coverage of nova.privsep.fs. https://review.openstack.org/648602
12:23:48 gibi kashyap: you really want me to read that spec :)
12:24:13 openstackgerrit Merged openstack/nova master: Improve test coverage of nova.privsep.fs, continued. https://review.openstack.org/648603
12:25:08 kashyap gibi: 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:34 gibi kashyap: ohh, I looked at the line 41 instead.
12:25:54 kashyap gibi: Yep, that is fairly uncontroversial. (Says the guy who proposed it.)
12:25:54 gibi kashyap: anyhow I'm reading the spec at l41 now :)
12:25:57 kashyap Thanks!
12:26:13 kashyap I need to be AFK in 35 mins; will respond on the change for any feedback
12:26:26 kashyap jaypipes: 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" :D
12:27:30 jaypipes kashyap: yep, today is spec review day.
12:37:11 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models https://review.openstack.org/642030
12:40:14 bauzas kashyap: sean-k-mooney: sorry was afk for lunch
12:40:22 bauzas so I missed your pings
12:40:32 bauzas don't take a -1 for a passive-aggressive method
12:40:46 bauzas it's just "I disagree with the current patch, because of : X, Y"
12:41:09 kashyap bauzas: No worries; it's all sorted
12:41:12 bauzas and my -1 is not about the naming, but rather about the fact that operators should provide a list ordered
12:41:24 kashyap bauzas: Yeah, saw your question; see the response from Sean and me...
12:41:34 sean-k-mooney bauzas: yes i know. that is how i use it too.
12:42:00 bauzas I'll look at the comments, for the moment, I'm looking at other spec
12:48:54 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Add instance hard delete https://review.openstack.org/570202
12:48:55 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Add requested_networks to RequestSpec https://review.openstack.org/570201
12:48:55 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Enable rebuild for instances in cell0 https://review.openstack.org/570203
12:49:50 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Introduce the PENDING instance state https://review.openstack.org/566473

Earlier   Later