| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 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 | |
| 21:17:51 | mriedem | *410 | |
| 21:17:59 | efried | mm | |
| 21:18:16 | mriedem | this is just like if we remove the nova-cells and nova-network services, the APIs that rely on those will just not work | |
| 21:18:33 | mriedem | well, won't work in train - might work in stein | |
| 21:18:43 | efried | right; which we're fine with | |
| 21:18:53 | efried | But, are you considering taking this on in train? | |
| 21:19:05 | efried | or hoodwinking stephenfin into doing so :P | |
| 21:19:07 | sean-k-mooney | by the way i moved the ci stuff here https://etherpad.openstack.org/p/nova-ptg-train-ci but im not really sure what we want to get out of it | |
| 21:19:23 | mriedem | efried: it's not really much to take on | |
| 21:19:31 | efried | sean-k-mooney: Good, since you're here, that's a question I'm basically trying to ask everyone about their topics. | |
| 21:19:55 | mriedem | rm -rf nova/console | |
| 21:19:56 | efried | mriedem: death of a thousand cuts? | |
| 21:20:12 | mriedem | this is definitely not a priority for me | |
| 21:20:47 | efried | k. I'll fup on the ML like I did for the privsep topic, proposing to cut it from the agenda unless objections. | |
| 21:21:05 | mriedem | i see the tc has a ptg item about "can we just start breaking stuff so people can get all the fancy new awesome cloud stuff" so we could just drop, say it's the tc's fault, and then move on | |
| 21:22:19 | efried | perfect | |
| 21:34:11 | sean-k-mooney | efried: can you get some of the intel folks to attend https://etherpad.openstack.org/p/nova-ptg-train-ci that will be setting up/runing the cis | |
| 21:35:21 | efried | hrm, I'm actually not sure if our boots-on-the-ground CI folk are going to be attending. | |
| 21:35:37 | efried | But I believe dtroyer is the, ahem, spokesperson for the effort. | |
| 21:37:12 | sean-k-mooney | ok well 2 of the feature intel is pushing for this cycle would need 3rd part ci. | |
| 21:37:20 | sean-k-mooney | persitent memeoy and rmd | |
| 21:37:36 | efried | oh, yes, we are well aware. | |
| 21:39:33 | aspiers | sean-k-mooney: do you have a suggestion for a resource class name instead of MEM_ENCRYPTED_CONTEXT? | |
| 21:40:34 | efried | sean-k-mooney: I can see you're still working on that agenda; as you go along, if you could be thinking about what we hope to achieve in the room, that we actually need to all be in a room for, that would be neat. | |
| 21:40:36 | sean-k-mooney | if we combine it with the trait i think it fine but i was also oke with SEV_CONTEXT | |
| 21:41:08 | aspiers | efried: sean-k-mooney's earlier suggestion of trait:HW_CPU_AMD_SEV=forbidden as a valid use case has finally sunk in. It seems to me that operators could use this in flavors as soon as the SEV code merged, for keeping non-SEV guests off SEV machines. | |
| 21:41:28 | sean-k-mooney | efried: well i would like mriedem input on that | |
| 21:42:02 | aspiers | Of course this would mean providing the trait from day 0, but I'm tempted to think that it's already a compelling enough use case that maybe I should propose that in the spec | |
| 21:42:17 | sean-k-mooney | this item basicaly came form the fact the nfv ci went way(on the nova side) and we got a bunch of new numa/hardware feature requests | |
| 21:42:18 | efried | if it's important to keep SEV-capable machines free of non-SEV instances. Do we care? | |
| 21:42:32 | aspiers | I would definitely expect some operators to want that, yes | |
| 21:42:51 | sean-k-mooney | aspiers: some but not all | |
| 21:42:53 | sean-k-mooney | ? | |
| 21:42:58 | aspiers | Surely it would be likely that a compute plane would be mostly non-SEV hosts, with a few SEV hosts to cater for the more demanding customers | |
| 21:43:23 | aspiers | sean-k-mooney: sorry, you lost me - not all what? | |
| 21:43:35 | efried | Okay. Then cool, I have no problem reintroducing the trait for that purpose - and also the future purpose of being able to distinguish between different mem encryption technologies. | |
| 21:43:36 | sean-k-mooney | aspiers: i think the quest efiried is asking is it required for it to work | |
| 21:44:11 | efried | no, I was just asking whether it matters that we consume non-sev-context resources on a sev-capable machine | |
| 21:44:13 | aspiers | It's probably not *required*, but the trait is already in os-traits and the code to provide it is already working, so ... :) | |
| 21:44:31 | aspiers | efried: Yes, I think it would matter to many operators | |
| 21:44:42 | efried | aspiers: Yes, and adding the trait at the same time as you add the context inventory is trivial, and enables this use case with no additional work. | |
| 21:44:48 | aspiers | AFAIK SEV hardware is still niche (and maybe more expensive too, I dunno) | |
| 21:44:54 | aspiers | efried: exactly | |
| 21:45:03 | efried | other than that 2LOC in update_provider_tree, you get to write a paragraph in the docs. That's it. | |
| 21:45:10 | aspiers | Right | |
| 21:45:28 | aspiers | I'll mention the potential future use case too | |
| 21:45:47 | efried | except... didn't we have a better way to turn on a "don't land here" by default? | |
| 21:45:56 | efried | rather than having to put it in every non-SEV flavor? | |
| 21:46:08 | aspiers | Probably not | |
| 21:46:11 | efried | Forbidden aggregates... | |
| 21:46:19 | aspiers | Oh | |
| 21:46:27 | aspiers | And required traits would override that? | |
| 21:46:38 | efried | https://review.openstack.org/#/c/609960/ | |
| 21:47:05 | efried | it's... a little complicated. | |
| 21:47:21 | aspiers | hah | |
| 21:47:25 | aspiers | but similar looking | |
| 21:47:29 | sean-k-mooney | efried: you mean the RP forbiden traits feature i suggested liek a year ago or soemthing else | |
| 21:47:54 | sean-k-mooney | * RP required tratis | |
| 21:48:01 | sean-k-mooney | wwell actuly it was both | |