| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 18:17:56 | sean-k-mooney | maybe | |
| 18:18:09 | efried | sean-k-mooney: exactly | |
| 18:18:26 | efried | if you don't care which technology you use, omit the traits | |
| 18:18:53 | efried | If you want to restrict to one (or more - I think we implemented traits=in:[list], didn't we?) use traits. | |
| 18:19:05 | sean-k-mooney | aspiers: i forget does the guest need to do anything to use sev | |
| 18:19:18 | sean-k-mooney | e.g. would an app in the guest care | |
| 18:19:29 | aspiers | The difference is that the presence of HW_CPU_AMD_SEV implies MCM_ENC_CTX, whereas HW_CPU_X86_AVX512F doesn't imply VCPU:1 (because AFAIK you can't have a guest without a vcpu) | |
| 18:19:33 | sean-k-mooney | or is it jsut something that the host/qemu need to care about | |
| 18:20:02 | aspiers | sean-k-mooney: just the host I think, apart from UEFI boot | |
| 18:20:07 | efried | aspiers: say wha? What sense would HW_*CPU*_X86_AVX512F make if you weren't using any CPUs? | |
| 18:20:44 | aspiers | efried: I didn't explain it very well, but my point was that VCPU:1 is essentially a no-op | |
| 18:21:01 | aspiers | s/1/2/ and my point is much clearer | |
| 18:21:20 | efried | nope, sorry, not following you. | |
| 18:21:23 | sean-k-mooney | i see you point but form a placement point of view a VCPU and SEV context are both jsut resouces | |
| 18:21:32 | sean-k-mooney | it doesnt care | |
| 18:21:38 | sean-k-mooney | and traits are jsut strings | |
| 18:21:49 | aspiers | sure, but efried was saying we should avoid duplication | |
| 18:22:08 | aspiers | HW_CPU_AMD_SEV implies MEM_ENC_CTX:1 therefore there is duplication | |
| 18:22:18 | aspiers | whereas with VCPU:2&HW_CPU_X86_AVX512F there is none | |
| 18:22:25 | aspiers | both constraints are needed in the latter, but not in the former | |
| 18:22:45 | efried | I've said I want two VCPUs. They have to support x86 AVX 512F. If I just say "I want x86 AVX 512F", you still don't know how many VCPUs I want. I could theoretically have made HW_CPU_X86_AVX512F a resource class so I could just say HW_CPU_X86_AVX512F=2 | |
| 18:22:55 | sean-k-mooney | we are ratholeing i think :) | |
| 18:22:55 | efried | but then I would need a separate flavor for every possible flag | |
| 18:23:03 | mriedem | melwitt: heh you said the same as i did before i could post it https://review.openstack.org/#/c/653145/ | |
| 18:23:19 | efried | and couldn't ever say "I'll accept any one of these variants" | |
| 18:23:21 | efried | etc etc. | |
| 18:23:34 | efried | That's why we have quantitative and qualitative separated. | |
| 18:23:45 | aspiers | I think we're on the same page, but I was responding specifically to the example you were describing as equivalent | |
| 18:23:48 | melwitt | mriedem: hah, nice | |
| 18:24:00 | aspiers | I don't think that specific example exhibits equivalence | |
| 18:24:03 | efried | There I go again using a poor specific example. | |
| 18:24:16 | aspiers | but yeah if you made HW_CPU_X86_AVX512F a resource class that would be a totally different thing | |
| 18:24:22 | aspiers | ;) | |
| 18:24:28 | efried | I actually haven't a clue what AVX512F means. | |
| 18:24:33 | efried | Or, for that matter, SEV | |
| 18:24:33 | aspiers | haha, nor me | |
| 18:24:44 | aspiers | I know it's a CPU flag though ;-) | |
| 18:24:46 | efried | just that both are qualitative characteristics of a thing. | |
| 18:25:20 | aspiers | anyway I have enough to go on for another patch set | |
| 18:25:25 | efried | cool | |
| 18:25:34 | aspiers | are you around much longer today? | |
| 18:25:47 | aspiers | just wondering if it's worth trying to get it done shortly | |
| 18:25:54 | efried | aspiers: was going to say, in further response to your "almost ready" question, that if we got an ack from danpb at this point, I would +2 with the discussed changes. | |
| 18:26:02 | efried | I'm around for at least another 3.5h | |
| 18:26:23 | aspiers | OK I'll try to ditch the trait removal then | |
| 18:26:35 | aspiers | which timezone is danpb? | |
| 18:26:55 | efried | ...noting of course that I still definitely want someone like jaypipes to weigh in on the using-rc-vs-trait shift. | |
| 18:26:59 | efried | no idea. | |
| 18:27:06 | aspiers | oh yeah, me too :) | |
| 18:27:13 | aspiers | don't know if he's around though | |
| 18:27:18 | mriedem | UK | |
| 18:27:21 | mriedem | london i think specifically | |
| 18:27:35 | aspiers | no way! | |
| 18:27:41 | aspiers | that's where I am | |
| 18:27:43 | aspiers | had no idea | |
| 18:27:45 | mriedem | he's your neighbor you weird hermit | |
| 18:27:48 | aspiers | haha | |
| 18:27:59 | mriedem | he's probably in your garden right now | |
| 18:28:09 | mriedem | by garden i mean "back yard" | |
| 18:28:16 | aspiers | I have a garden | |
| 18:28:22 | aspiers | communal, but I'm counting it | |
| 18:28:26 | efried | anyway, aspiers, I'm not sure we're shooting to get this merged today, but couldn't hurt to have a ps without a blocking issue (os-traits reduction) in it for whenever those guys do get to looking. | |
| 18:28:27 | aspiers | hrm, need to google a pic of him first | |
| 18:28:35 | aspiers | efried: agreed | |
| 18:28:44 | aspiers | I'll try to address shortly | |
| 18:28:52 | efried | thanks for your patience aspiers | |
| 18:29:00 | aspiers | efried: likewise!! | |
| 18:40:53 | artom | We do beg your pardon, we are in your garden | |
| 18:47:13 | aspiers | X-D | |
| 19:30:17 | openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: [WIP] Validate that ironic_url works with regions https://review.openstack.org/653839 | |
| 19:39:55 | openstackgerrit | Merged openstack/nova master: Remove old-style cell v1 instance listing https://review.openstack.org/651296 | |
| 19:41:51 | efried | mriedem: Since Spec: https://review.openstack.org/#/c/645458/ (Add host and hypervisor_hostname flag to create server) is merged/approved, can I strike it from the PTG agenda? | |
| 19:44:46 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_usages_counts_for_quota to SchedulerReportClient https://review.openstack.org/653145 | |
| 19:44:47 | openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | |
| 19:44:47 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 19:44:48 | openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.openstack.org/653845 | |
| 19:44:48 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 19:45:00 | mriedem | efried: i think so | |
| 19:45:05 | efried | thx | |
| 19:47:36 | openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.openstack.org/653845 | |
| 19:48:49 | openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.openstack.org/653845 | |
| 20:16:35 | openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: [WIP] Validate that ironic_url works with regions https://review.openstack.org/653839 | |
| 20:41:03 | openstackgerrit | Merged openstack/nova stable/queens: Add functional recreate test for bug 1819963 https://review.openstack.org/648414 | |
| 20:41:05 | openstack | bug 1819963 in OpenStack Compute (nova) queens "Reverting a resize does not update the instance.availability_zone value to the source az" [Medium,In progress] https://launchpad.net/bugs/1819963 - Assigned to Matt Riedemann (mriedem) | |
| 20:42:57 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197 | |
| 21:07:40 | efried | mriedem: re deprecating nova-console: I read http://lists.openstack.org/pipermail/openstack-dev/2018-October/135422.html as "no objections". Is there anything to be gained by discussing it at the PTG, someone who happens to be in the room voicing an objection? | |
| 21:09:00 | efried | "...PTG, *beyond* someone who happens to be in the room..." | |
| 21:13:35 | sean-k-mooney | efried: maybe at the fourm | |
| 21:13:43 | sean-k-mooney | get operators to weigh in | |
| 21:14:58 | efried | It just seems pretty hit or miss to me. We ask the question and nobody responds, we're not really any better off than we were. Maybe the guy who cares just left the room, or isn't at the summit, or whatever. | |
| 21:15:52 | efried | I would think the ML would be a better way to canvass the right cross-section of people. And that's been done. | |
| 21:16:03 | sean-k-mooney | well we can deprecated it in train and then the have until U to say "hay we use that" | |
| 21:16:13 | efried | Then we deprecate it for a release or two (or six, viz. nova-network), giving people yet more time to make noise. | |
| 21:16:18 | mriedem | efried: i agree that the ML is likely better than the PTG since i don't expect any xen/citrix people to be at the ptg | |
| 21:16:40 | mriedem | Bob's reply in the ML wasn't exactly clear to me about there being a replacement people are using | |
| 21:16:58 | mriedem | the service has already been deprecated technically | |
| 21:16:59 | efried | mriedem: ack. I was focusing on the part where he said "yeah, deprecate" | |
| 21:17:27 | efried | mriedem: okay. I'm going to put it at the bottom of the list, for like 4:55pm Saturday. | |
| 21:17:44 | efried | do you want to fup on the ML? or want me to do so? Or leave it alone? | |
| 21:17:49 | mriedem | deprecated as of stein https://review.openstack.org/#/c/610075/ - the bigger question for me was if we drop the service, the APIs have to also start returning a 401 | |