| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-09 | |||
| 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 | gibi | kashyap: anyhow I'm reading the spec at l41 now :) | |
| 12:25:54 | kashyap | gibi: Yep, that is fairly uncontroversial. (Says the guy who proposed it.) | |
| 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: Enable rebuild for instances in cell0 https://review.openstack.org/570203 | |
| 12:48:55 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Add requested_networks to RequestSpec https://review.openstack.org/570201 | |
| 12:49:50 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Allow rebuild for instances in PENDING state https://review.openstack.org/637585 | |
| 12:49:50 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Introduce the PENDING instance state https://review.openstack.org/566473 | |
| 12:50:48 | efried | kashyap: ack | |
| 12:51:41 | sean-k-mooney | its surpring how often "sudo rm -rf /var/lib/docker/" fixs your docker issues | |
| 12:51:49 | efried | I at least diff from the last release's version before doing that; this one has changed substantially so I'll wait | |
| 12:52:39 | efried | What's the adage? "If you try to solve a problem using docker, now you have two problems." ? | |
| 12:53:47 | efried | Welcome to Train pre-PTG spec review day #1: https://etherpad.openstack.org/p/nova-spec-review-day | |
| 12:53:47 | efried | dansmith: Would you please update the channel topic to something like | |
| 13:13:11 | openstackgerrit | Huqiang Wang proposed openstack/nova-specs master: Separate the vCPUs into different pools based on priority https://review.openstack.org/649882 | |
| 13:19:53 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Nova LLC allocation - RMD plugin for RDT CAT https://review.openstack.org/651233 | |
| 13:21:29 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Use migration_status during volume migrating and retyping https://review.openstack.org/637224 | |
| 13:37:26 | kashyap | sean-k-mooney: On "Docker", you're so 2014. 'Everyone' has moved on from Docker to "CRI-O" and "podman", etc. | |
| 13:37:43 | kashyap | (Please update your "container jargon" :D) | |
| 13:38:55 | sean-k-mooney | kashyap: i am using docker and plan to never use podman. i might use CRI-O | |
| 13:39:31 | kashyap | sean-k-mooney: I was massively trolling; sorry. (I have no clue about their compatibilities.) | |
| 13:41:33 | sean-k-mooney | podman has 1:1 commandline compatible with docker | |
| 13:41:44 | sean-k-mooney | or the docker cli | |
| 13:42:16 | sean-k-mooney | cri-o is interesting but its non tivial to setup currently | |