| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-09 | |||
| 07:29:41 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Add "CPU selection with hypervisor consideration" spec https://review.openstack.org/645814 | |
| 07:31:25 | bauzas | kashyap: just leave a comment in https://review.openstack.org/#/c/642030/ saying you'd like to not have the spec quick approved | |
| 07:31:39 | bauzas | quickly* (or fast) | |
| 07:44:40 | kashyap | bauzas: 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 spec | |
| 07:45:09 | kashyap | bauzas: I'm writing a more thorough comment after some thinking last evening. | |
| 07:50:01 | kashyap | bauzas: Maybe a silly question: Can tenant users create flavors? | |
| 07:50:36 | bauzas | kashyap: there is no silly question | |
| 07:50:54 | bauzas | kashyap: flavors are managed by admins, but that's just a policy | |
| 07:50:59 | kashyap | Right | |
| 07:51:24 | bauzas | that's the main different between image metadata and flavor extra specs | |
| 07:51:39 | bauzas | ones are admin-defined, the others are user-defined | |
| 07:54:00 | kashyap | bauzas: Ah, noted; so flavor extra_specs are user-defined. | |
| 07:55:48 | kashyap | Thanks! | |
| 07:58:09 | bauzas | kashyap: uh that's not what I said :) | |
| 07:58:22 | bauzas | sorry, I flipped the answer | |
| 07:58:39 | kashyap | Err, it's the other way round. | |
| 07:59:08 | bauzas | kashyap: https://docs.openstack.org/nova/latest/configuration/policy.html | |
| 07:59:35 | bauzas | os_compute_api:os-flavor-extra-specs:create Default rule:admin_api Operations POST /flavors/{flavor_id}/os-extra_specs/ | |
| 08:00:13 | bauzas | but as a user, you can see the flavor extra specs | |
| 08:00:23 | kashyap | Nod | |
| 08:00:32 | openstackgerrit | Kunpeng Zhang proposed openstack/nova master: Enhance live-migration progress log for memory and block data https://review.openstack.org/650621 | |
| 08:06:01 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Implements: blueprint nova-local-resource-management-that-uses-rmd https://review.openstack.org/651130 | |
| 08:17:00 | kashyap | bauzas: 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:14 | kashyap | s/flavors right?/flavors, right?/ | |
| 08:17:40 | bauzas | kashyap: you don't "set" a trait on a flavor, but you rather add a trait as an extra spec field | |
| 08:17:49 | bauzas | so, yeah to what you said | |
| 08:17:59 | kashyap | bauzas: Noted, thanks for correcting :-) | |
| 08:18:02 | bauzas | you 'set' a trait on a RP | |
| 08:18:38 | kashyap | (Ah, Resource Provider; I don't much about them. For now, I'll table that topic. ) | |
| 08:18:39 | bauzas | kashyap: no worries, just explaining for you and also other folks | |
| 08:19:44 | kashyap | Thx. | |
| 08:20:23 | kashyap | yaawang: 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:49 | kashyap | yaawang: 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:39:30 | yaawang | kashyap: OK, do we need to open a zoom call to figure out some of the questions? | |
| 08:39:47 | kashyap | What is a "zoom call"? | |
| 08:40:09 | kashyap | I think I will write up the questions, so that those who are not present can also read them. | |
| 08:40:14 | kashyap | (And it serves as a record as well.) | |
| 08:42:30 | yaawang | s/zoom call/online meeting/ | |
| 08:43:27 | yaawang | kashyap: OK, I agree with you. When can you send the email? | |
| 08:44:06 | kashyap | yaawang: By end of today (I'm in CEST) | |
| 08:46:15 | yaawang | kashyap: Got it, thanks. | |
| 08:48:07 | openstackgerrit | Boxiang Zhu proposed openstack/nova-specs master: Expose live migration tunnelled in rest api https://review.openstack.org/651139 | |
| 09:29:05 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.openstack.org/649953 | |
| 09:33:05 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Re-propose stable device rescue for Train https://review.openstack.org/651151 | |
| 10:07:20 | frickler | is 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-deploy | |
| 10:54:58 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec https://review.openstack.org/506720 | |
| 10:58:27 | kashyap | bauzas: Please don't "-1" based on "bad feelings": https://review.openstack.org/#/c/642030/ | |
| 10:58:37 | kashyap | If you have a good rationale, then do so. Otherwise, just leave a comment. | |
| 10:59:16 | sean-k-mooney | kashyap: i have not read it but i think -1 form a core because they have bad feels about something is not unwarrented | |
| 10:59:25 | kashyap | bauzas: Also, no -- just using the plural `cpu_models` is _not_ "simple". It can cause confusion | |
| 10:59:44 | kashyap | Please read the commit message, where I outlined _why_ we should use the name I proposed. | |
| 11:00:37 | kashyap | sean-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:01:34 | kashyap | Maybe I'm feeling a bit cranky with too many things going on ... don't take me _too_ seriously :-) | |
| 11:01:47 | sean-k-mooney | kashyap: when you have core right you can be more granular as you can -2 when you really have stong feeling somthing shoudl not be done | |
| 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 | |