| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-08 | |||
| 19:48:42 | mriedem | we don't reschedule within superconductor... | |
| 19:49:00 | dansmith | but we can | |
| 19:49:14 | dansmith | we don't currently because we shouldn't need to | |
| 19:49:36 | dansmith | scheduler re-queries if it can't claim resources, and conductor doesn't know if a compute will fail, so it can't reschedule at that point, | |
| 19:49:55 | dansmith | but if we have a reason, like we go create the instance in a cell, and then learn we lost the race, we can reschedule before we map that instance | |
| 19:50:51 | dansmith | you know, | |
| 19:52:10 | dansmith | I was going to spout off another potential way to solve the need for the affinity upcall in a similar way, but I need to think about that for a sec | |
| 19:52:29 | dansmith | but regardless for the cell race I think we can manage it in superconductor | |
| 19:54:51 | sean-k-mooney | dansmith: is there any reason we dont create placement aggregates for cells out of interest? | |
| 19:55:24 | melwitt | I hope somebody can write down these ideas somewhere so we don't forget in stein | |
| 19:55:41 | sean-k-mooney | if we did that consider a cell is just a member-of right? | |
| 19:56:14 | sean-k-mooney | all the info to create the aggregate is already in the cell mapping table | |
| 19:56:24 | dansmith | sean-k-mooney: I don't want to leak cells outside of nova in any way | |
| 19:56:44 | dansmith | sean-k-mooney: and I definitely don't want to auto-create aggregates in nova that align to cells | |
| 19:57:18 | sean-k-mooney | dansmith: aggregates in placement auto-created by nova you mean | |
| 19:57:54 | dansmith | sean-k-mooney: definitely not auto-created in nova, but probably not really in placement either | |
| 19:59:35 | dansmith | we can already filter hosts by cell in the scheduler | |
| 19:59:36 | sean-k-mooney | well a placement aggreate is just a group of resouce providers. there is no real inherint semantics beyond that. so you can model cells or regions or host aggregats equally | |
| 20:00:23 | sean-k-mooney | dansmith: true but if there was a agregate associated with placement could ignore everything not in that aggregate | |
| 20:00:44 | sean-k-mooney | anyway its just an idea. | |
| 20:00:55 | openstackgerrit | Merged openstack/nova master: Refactor cell_type in compute/api.py https://review.openstack.org/589833 | |
| 20:21:07 | melwitt | mriedem: don't forget to please review these ocata quota fixes before you go on vacay https://review.openstack.org/588416 and the one above it | |
| 20:22:17 | mriedem | oh right | |
| 20:39:46 | openstackgerrit | melanie witt proposed openstack/nova master: Add a prelude release note for the 18.0.0 Rocky GA https://review.openstack.org/589303 | |
| 20:51:13 | openstackgerrit | Sergii Golovatiuk proposed openstack/nova master: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/589548 | |
| 21:07:00 | openstackgerrit | Sergii Golovatiuk proposed openstack/nova master: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/589548 | |
| 21:13:30 | openstackgerrit | Jay Pipes proposed openstack/nova master: split gigantor SQL placement query into multiple https://review.openstack.org/590041 | |
| 21:16:14 | jaypipes | mriedem, dansmith: is there a way to boot a Nova VM on behalf of another user/project? | |
| 21:16:30 | dansmith | I think that has been requested before | |
| 21:16:38 | jaypipes | mriedem: alternately, is there a way to transfer ownership of an instance once its been created? | |
| 21:16:50 | dansmith | also requested | |
| 21:16:54 | jaypipes | pretty sure that latter thing has been requested a few times, yeah | |
| 21:16:57 | melwitt | haha, Oath questions | |
| 21:17:00 | dansmith | yup | |
| 21:17:01 | jaypipes | :) | |
| 21:17:16 | jaypipes | melwitt: yup. trying to see if we can chuck the "ytenant" patches. | |
| 21:18:47 | melwitt | yeah, I kept talking about it for years "on behalf of" but there's not even support for that in keystone either, from what I understand. there's no such thing as a credential that records "I am A and I have obtained a token for B" | |
| 21:18:59 | jaypipes | mriedem, dansmith: BTW, https://review.openstack.org/#/c/590041 is all about that "debugging scheduler filters" thing... | |
| 21:19:22 | jaypipes | mriedem, dansmith: or rather the "NoValidHosts oh noes!" thing. | |
| 21:19:34 | jaypipes | bnemec-pto: https://review.openstack.org/#/c/590041 | |
| 21:19:34 | dansmith | both would be complicated, especially around image, flavor, and affinity things that would be violated by the new tenant | |
| 21:19:38 | openstackgerrit | Merged openstack/nova master: xx_instance_type_id in list_migrations should be integer https://review.openstack.org/588481 | |
| 21:20:08 | melwitt | yeah, transfer of ownership would be very difficult | |
| 21:23:18 | melwitt | but for "on behalf of", an idea I had was if we were to take a --project-id, --user-id parameter to nova boot, that you could pass if you're admin, then we create the instance with the given project/user instead of the admin's. and we'd have to record in the logs that it happened, "Project/user admin/admin has requested instance create for person/person" so it's traceable in some way | |
| 21:24:08 | dansmith | well, | |
| 21:24:18 | dansmith | presumably you get admin's access to images and flavors? | |
| 21:24:28 | dansmith | so what do we do if the user tries to rebuild? | |
| 21:24:31 | dansmith | or resize? | |
| 21:24:47 | dansmith | and do you get admin's affinity or the user's? | |
| 21:24:52 | melwitt | the project/user recorded in the database will be theirs (the user's), not the admins | |
| 21:24:54 | dansmith | what about when they rebuild/resize/etc? | |
| 21:24:59 | melwitt | after the admin creates it, no more admin involved | |
| 21:25:34 | dansmith | which means they can't rebuild if the admin built with an image they can't access yeah? | |
| 21:25:38 | jaypipes | dansmith: it's a "let's have the admin hand-hold you for a little while, then after that, you can use it" sort of anti-feature. | |
| 21:25:46 | melwitt | dansmith: yeah | |
| 21:25:52 | dansmith | jaypipes: yes, anti-feature is a good name for it :) | |
| 21:26:02 | melwitt | yeah. I can't really remember why they want it | |
| 21:26:19 | dansmith | jaypipes: without a lot of inbuilt support for that workflow, it sounds like the kind of thing that will always have a million caveata | |
| 21:26:22 | dansmith | like shelve | |
| 21:26:58 | melwitt | because admin can act upon all user's instances already, except for create, if I'm remembering correctly | |
| 21:27:07 | melwitt | that is, an admin can delete a normal user's instance, etc | |
| 21:27:40 | dansmith | well, that's a terrible reason, but I know what you mean :) | |
| 21:27:59 | melwitt | haha, sorry, wasn't using it as a reason | |
| 21:28:55 | melwitt | I mentioned it in the context of, I can't remember why they need it for create, being that admin can already do everything else to normal user instances | |
| 21:29:06 | dansmith | I know | |
| 21:31:34 | melwitt | jaypipes: fwiw, you might be able to solve it at the keystone level, like if you could present keystone with admin creds and then receive back a token for another user (if you have the appropriate role), then it would be transparent to nova. the context nova receives would be for the wanted user | |
| 21:32:37 | melwitt | like if there were a role, "Allowed to act on behalf of project X" that admin type users could be a part of | |
| 21:33:59 | dansmith | or write a half page doc for your users on how to boot their first instance | |
| 21:34:46 | mriedem | dansmith: we have a bug for that with shelve, | |
| 21:34:48 | melwitt | yeah, I can't remember what it's for, something automated where a headless user is doing it | |
| 21:34:49 | mriedem | user creates server, | |
| 21:34:51 | mriedem | admin shelves it, | |
| 21:34:55 | mriedem | user unshelves, | |
| 21:34:59 | mriedem | kablammo | |
| 21:35:00 | dansmith | boom | |
| 21:35:01 | dansmith | heh yeah | |
| 21:35:03 | mriedem | b/c user doesn't have access to the admin snapshot | |
| 21:35:08 | dansmith | yar | |
| 21:35:12 | melwitt | that's fun | |
| 21:35:27 | melwitt | I guess the keystone idea would solve that issue | |
| 21:35:34 | mriedem | i'm pretty sure it's a relatively straight-forward fix, just haven't ever had the proper motivation to work on it | |
| 21:35:41 | mriedem | no no no | |
| 21:35:56 | mriedem | when we snapshot, we make the instance owner (the user) have member access to the image | |
| 21:36:00 | mriedem | glance has a thing for that | |
| 21:36:30 | mriedem | https://specs.openstack.org/openstack/glance-specs/specs/api/v1/requesting_image_memberships.html | |
| 21:36:55 | mriedem | https://specs.openstack.org/openstack/glance-specs/specs/api/v1/adding_a_member_to_an_image.html | |
| 21:36:58 | melwitt | neat | |
| 21:37:41 | mriedem | https://bugs.launchpad.net/nova/+bug/1675791 | |
| 21:37:41 | openstack | Launchpad bug 1675791 in OpenStack Compute (nova) "Instance created by demo user(non-admin), shelved by admin and unshelved by demo user --> ends up in error state " [Medium,Triaged] - Assigned to Damini Chopra (damini) | |
| 21:38:09 | openstackgerrit | Merged openstack/nova master: Add explicit functional-py36 tox target https://review.openstack.org/589825 | |
| 21:38:19 | openstackgerrit | Merged openstack/nova master: Add the guideline to write API reference https://review.openstack.org/569058 | |
| 21:39:55 | mriedem | speaking of changing stuff on unshelve https://review.openstack.org/#/c/559828/ | |
| 21:40:44 | melwitt | you've opened the shelve bug bin | |
| 21:42:06 | mriedem | time to create a shelve sig | |
| 21:42:10 | mriedem | / support group | |
| 21:42:18 | mriedem | for admins that have enabled that api | |
| 21:42:32 | melwitt | lol | |
| 21:53:45 | mriedem | melwitt: dansmith: a couple of thoughts in this ocata-only func test https://review.openstack.org/#/c/588416/ | |
| 21:53:57 | mriedem | if you wanted to make it less unit-y | |
| 21:55:21 | dansmith | mriedem: I definitely think this is a unit test, as I said | |