| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 18:15:20 | sean-k-mooney | ya | |
| 18:15:25 | aspiers | efried: +1 ;-) | |
| 18:16:00 | sean-k-mooney | ok im going to have dinner ill try and review the sepc again before i sign off for the long weekend | |
| 18:16:19 | aspiers | sean-k-mooney: thanks! | |
| 18:16:19 | sean-k-mooney | aspiers: efried i take it taht we are close however on the spec? | |
| 18:16:32 | aspiers | it feels close to me but I'm usually over-optimistic | |
| 18:16:39 | efried | aspiers: The inventory (resource class) is telling you how many of a thing your provider can give. The trait is telling you characteristics of the provider. I don't really see a difference between VCPU:1&HW_CPU_X86_AVX512F:required and MEM_ENC_CTX:1&HW_CPU_AMD_SEV:required | |
| 18:17:03 | efried | aspiers: I feel we're close on the bits I understand, yes :) | |
| 18:17:08 | aspiers | hehe | |
| 18:17:21 | sean-k-mooney | efried: yes that is a fair comparison | |
| 18:17:51 | aspiers | I see a big difference actually | |
| 18:17:54 | sean-k-mooney | so we could have MEM_ENC_CTX:1&HW_CPU_INTEL_MKTME:required also | |
| 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 | |