| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-31 | |||
| 19:21:00 | mriedem | https://espaces.edu.au/vwrangler/nectar-topics/nectar-how-tos/using-nova-rescue-to-repair-a-nectar-instance | |
| 19:21:23 | JayF | that one says "admin" | |
| 19:21:28 | mriedem | i'm not totally sure, but i think the username depends on the image used | |
| 19:21:29 | JayF | Rackspace uses root | |
| 19:21:36 | JayF | Yeah, that's what I was afraid of | |
| 19:21:42 | JayF | since ironic provides the image we have to just decide | |
| 19:22:16 | clarkb | fwiw if it were me, I would expect root | |
| 19:22:56 | JayF | We have it written today for "rescue@" | |
| 19:23:13 | JayF | I think root is more reasonable... but it's unfortunate that it's not dictated | |
| 19:23:19 | JayF | someone, just tell me what to do :P | |
| 19:24:02 | mriedem | dictated by the user making the rescue request? | |
| 19:24:14 | JayF | dictated by a document, or something like that | |
| 19:24:25 | mriedem | because the admin on a windows rescue image is going to be Administrator, right? | |
| 19:24:31 | JayF | I just want to be told what right is, because there being no "right answer" means I have to document the hell out of it | |
| 19:24:45 | JayF | we don't support arbitrary rescue images in ironic's implementatino | |
| 19:24:59 | JayF | not really possible since we're implementing rescue as booting a ramdisk and configuring it | |
| 19:25:00 | clarkb | also you should be able to rescue windows with linux but the other direction is much harder | |
| 19:25:24 | clarkb | (there are even distros out there purpose built for this) | |
| 19:25:31 | mriedem | JayF: what are you going to do in the nova driver impl then? ignore the image ref passed in, or put the instance into error state? | |
| 19:25:49 | JayF | mriedem: ignore the one passed in, I think is how it's written | |
| 19:25:54 | JayF | mariojv: ^ you just looked at that patch, do you know? | |
| 19:25:55 | sdague_ | mriedem: ok, going through https://review.openstack.org/#/c/441692 with a deeper comb. While I realize that it probably isn't going to get done in Pike anyway, it does feel better on an expectation front to say that Pike is about getting an optional facility there for people to play around with instead of jumping all the way to recommended operating mode | |
| 19:26:19 | JayF | mriedem: I think we're happy doing whatever you think is right in that case, but imo ignoring the image request seems the sanest. | |
| 19:26:21 | mriedem | sdague_: isn't that what i said in there? i said a config option, disabled by default | |
| 19:26:35 | mriedem | JayF: that's not honoring the API... | |
| 19:26:49 | JayF | so you think we should put instance into error and raise an instance fault/ | |
| 19:26:51 | mriedem | so i'm not sure if it's better to fault and say you can't do that, or just ignore it | |
| 19:26:51 | JayF | ? | |
| 19:27:07 | JayF | I mean, technically, it's borderline impossible for us to respect the api with bare metal | |
| 19:27:13 | mriedem | putting the instance into error state is maybe something we shouldn't do | |
| 19:27:26 | mriedem | so it's a question of ignore, or fault | |
| 19:27:30 | sdague_ | https://review.openstack.org/#/c/441692/3/specs/pike/approved/list-instances-using-searchlight.rst@15 ... definitely leans in a different direction | |
| 19:28:15 | mriedem | https://review.openstack.org/#/c/441692/3/specs/pike/approved/list-instances-using-searchlight.rst@48 | |
| 19:28:21 | mriedem | "By default this path will be disabled." | |
| 19:28:34 | JayF | mriedem: I'll put a note on the nova patch for us to think about that case more explicitly -- right now we're trying to get the patches lined up to prove rescue working in tempest | |
| 19:29:08 | mriedem | JayF: fwiw, when you do boot from volume or attach a volume and provide a device name in the api, the libvirt driver totally ignores that device name and has since liberty | |
| 19:29:19 | mriedem | so we have some precedence for drivers ignoring the api | |
| 19:29:21 | clarkb | JayF: couldn't you publish a rescue image in glance that would be used if specified, and its up to use to figure it out if they specify something different? | |
| 19:29:27 | JayF | mriedem: prior are for ignoring the user, I'll take it :P | |
| 19:29:43 | JayF | clarkb: we're treating it similar to a provisioning ramdisk, configurable by operator/deployer only | |
| 19:30:05 | JayF | clarkb: and I would have to think hard about the security implications of letting an api end-user dictate an image to pxe boot | |
| 19:30:47 | JayF | clarkb: plus it's sorta ... setting up a user for failure. I'd rather ignore their image request than provide support for it, but have building an image that works be borderline impossible without special knowledge. | |
| 19:31:07 | clarkb | JayF: as a user of your APIs I really disagree on that last point | |
| 19:31:22 | clarkb | I'm really tired of clouds making bad decisions for me and forcing me to abide by them when there is no reason to | |
| 19:31:59 | clarkb | image upload is/was that same general problem. So what did people do they ran their own pxe servers and dd'd over ubuntu images with image that then booted pxe | |
| 19:32:54 | clarkb | (it may make sense here but as a general rule I'm not a fan of it) | |
| 19:32:54 | JayF | There /is/ a reason for it here: rescue is not some arbitrary image booted on a hypervisor, it's a ramdisk, that has to have proper hardware support, as well as a properly configured ironic-python-agent. As someone who has operated ironic clouds, I'm not sure I'd want any of my api users being able to pxe boot an arbitrary ramdisk on hardware | |
| 19:33:30 | clarkb | JayF: also fwiw I think your users likely can already pxe boot arbitrary ramdisks on hardware | |
| 19:33:47 | clarkb | (its a really common workaround for the I can't upload my own images problem) | |
| 19:34:00 | JayF | clarkb: not in an ironic configured for localboot only | |
| 19:34:16 | JayF | clarkb: they can localboot anything they want, but not pxe boot it directly from ironic's setup | |
| 19:34:28 | clarkb | JayF: you local boot the image that speaks pxe | |
| 19:34:54 | JayF | oh, I forgot the #1 reason why that likely shouldn't be allowed: | |
| 19:35:04 | JayF | we pxe boot the rescue ramdisk from an internal-use-only rescue network | |
| 19:35:14 | JayF | to flip it over to tenant networks before the rescue is complete | |
| 19:35:33 | JayF | so allowing arbitrary ramdisks to boot in rescue would be enabling a tenant to run arbitrary code inside your rescue network | |
| 19:35:43 | JayF | which would be a major security concern | |
| 19:45:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Ensure reservation_expire actually expires reservations https://review.openstack.org/452300 | |
| 19:50:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Ensure reservation_expire actually expires reservations https://review.openstack.org/452300 | |
| 20:01:21 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in security_groups.py https://review.openstack.org/452309 | |
| 20:15:42 | leakypipes | dansmith: is there such a thing as a cells.json file? | |
| 20:16:03 | dansmith | leakypipes: um, what? | |
| 20:16:20 | leakypipes | can you pop into #openstack-helm right quick? | |
| 20:16:25 | leakypipes | dansmith: ^^ | |
| 20:16:27 | leakypipes | as superdan :) | |
| 20:44:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Reraise reservation commit/rollback errors if not self-healing https://review.openstack.org/452319 | |
| 20:51:41 | mriedem | wow there was a whole lot of nothing going on in there | |
| 21:04:46 | openstackgerrit | Scott Moser proposed openstack/nova master: Limit exposure of network device types to the guest. https://review.openstack.org/400883 | |
| 21:15:35 | pramodrj07 | Hey All, | |
| 21:21:51 | pramodrj07 | Can anyone help me in understanding the differnece between security groups in nova and sg in neutron? | |
| 21:22:51 | mriedem | pramodrj07: security groups in nova are tied to nova-network, which has been deprecated since the newton release | |
| 21:23:17 | pramodrj07 | Oh cool! Thanks for clarification | |
| 21:23:26 | mriedem | the security group resource APIs were deprecated in the 2.36 microversion | |
| 21:24:14 | mriedem | you can provide security groups when creating a server, and nova will associate the security groups with ports that are attached to the server when creating it | |
| 21:24:33 | mriedem | assuming the network that the port is on enables port security | |
| 21:25:04 | pramodrj07 | Oh ok! So the latest cli client will call neutron security group API when we try to create a sg!? | |
| 21:26:27 | mriedem | which cli? nova boot or openstack server create? | |
| 21:26:45 | pramodrj07 | openstack security group create | |
| 21:26:55 | pramodrj07 | yes Openstack one | |
| 21:27:03 | mriedem | that is openstackclient and will use neutron if there is a network service type in the service catalog | |
| 21:28:57 | pramodrj07 | Oh ok! Gotcha! | |
| 21:30:49 | pramodrj07 | i am extending a plugin for rally to create sgs along with sg rules for neutron. I saw a similar scenario developed for nova. So wanted a clarification! | |
| 21:30:58 | pramodrj07 | Thanks a lot mriedem | |
| 21:31:47 | mriedem | yw | |
| 22:40:23 | mriedem | melwitt: here is the bug for the quota commit/rollback thing in the api https://bugs.launchpad.net/nova/+bug/1678326 | |
| 22:40:23 | openstack | Launchpad bug 1678326 in OpenStack Compute (nova) "Quota is decremented during instance delete in cell0 even if the instance destroy fails" [High,Triaged] - Assigned to Matt Riedemann (mriedem) | |
| 22:40:28 | mriedem | long-time coming on writing that | |
| 22:41:31 | mriedem | i don't have a good way of writing a regression test for that one really, unless i stub out instance.destroy() to raise InstanceNotFound to simulate concurrent deletes | |
| 22:41:43 | melwitt | mriedem: thanks for writing that up | |
| 22:42:38 | melwitt | I'm trying to remember how does the instance destroy fail | |
| 22:43:20 | mriedem | it could happen with concurrent delete requests couldn't it? | |
| 22:43:56 | melwitt | I just can't remember what happened to where we figured this out | |
| 22:46:04 | mriedem | idk, it was copied from _delete_while_booting | |
| 22:46:15 | mriedem | which was copied from _delete | |
| 22:46:26 | mriedem | which checks for that here https://github.com/openstack/nova/blob/88bc8dc5ce32748452c9d3acda9f35e77fedb6ce/nova/compute/api.py#L1806 | |
| 22:47:56 | mriedem | sorry wrong link there | |
| 22:48:01 | melwitt | looks like int32bit described it in a comment on https://bugs.launchpad.net/nova/+bug/1670627 but didn't say how delete failed | |
| 22:48:01 | openstack | Launchpad bug 1670627 in OpenStack Compute (nova) ocata "quota is always in-use after delete the ERROR instances " [Critical,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 22:48:09 | mriedem | https://github.com/openstack/nova/blob/88bc8dc5ce32748452c9d3acda9f35e77fedb6ce/nova/compute/api.py#L2025 | |
| 22:48:59 | melwitt | sorry, krims0n32 is the lp name | |