| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-09 | |||
| 04:44:59 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 04:46:08 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 05:10:51 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add in_tree field to RequestGroup object https://review.openstack.org/649534 | |
| 05:10:52 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree https://review.openstack.org/650878 | |
| 05:10:52 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add get_compute_nodes_by_host_or_node() https://review.openstack.org/650877 | |
| 05:10:53 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Query `in_tree` to placement https://review.openstack.org/649535 | |
| 05:28:14 | eandersson | I still wish you could add your own filters and weights as plugins. | |
| 05:29:32 | eandersson | Instead of having to roll your own version of nova and drop them in the appropriate folders. | |
| 05:36:44 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Use the functional test test_parallel_evacuate_with_server_group https://review.openstack.org/649963 | |
| 05:53:32 | openstackgerrit | Merged openstack/nova master: Remove query_client from resource_tracker https://review.openstack.org/650616 | |
| 07:17:49 | kashyap | efried: 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:18:12 | kashyap | The more I think of it, there are more questions than answers. And the author of the spec from Stein seems AWOL. | |
| 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 | |