| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-31 | |||
| 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 | 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:32:54 | clarkb | (it may make sense here but as a general rule I'm not a fan of it) | |
| 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 | 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: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: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 | 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: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:09 | mriedem | https://github.com/openstack/nova/blob/88bc8dc5ce32748452c9d3acda9f35e77fedb6ce/nova/compute/api.py#L2025 | |
| 22:48:59 | melwitt | sorry, krims0n32 is the lp name | |
| 22:49:08 | mriedem | yeah i was wondering about that | |
| 22:49:34 | mriedem | anyway, the old old code just says # NOTE(comstud): Race condition. Instance already gone. | |
| 22:49:38 | mriedem | again, this is all comstud's fault | |
| 22:49:55 | 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:49:55 | melwitt | https://bugs.launchpad.net/nova/+bug/1670627/comments/27 | |
| 22:50:05 | melwitt | heh | |
| 22:50:34 | mriedem | 2012 so who knows https://github.com/openstack/nova/commit/c729ba8c0aa4d283e84d139bc98e0e89fd933c4a | |
| 22:50:45 | mriedem | seemed like a good idea at the time | |
| 22:51:16 | mriedem | have you ever noticed this? https://github.com/openstack/nova/blob/88bc8dc5ce32748452c9d3acda9f35e77fedb6ce/nova/compute/api.py#L2010 | |
| 22:51:34 | mriedem | i bet ^ is wrong now with the cellsv2 local delete case too | |
| 22:51:39 | melwitt | yeah, I was just curious how it happened, mostly to make sure that's the only problem and there isn't some additional problem | |
| 22:52:35 | melwitt | yeah, I have seen that before but it gets glossed over bc soft-delete | |
| 22:53:14 | melwitt | it gets removed in my series (all reserve/commit/rollback removed) | |
| 22:53:41 | mriedem | i noticed it because of this https://github.com/openstack/nova/blob/88bc8dc5ce32748452c9d3acda9f35e77fedb6ce/nova/compute/manager.py#L2334 | |
| 22:53:55 | mriedem | the dumb thing is that we create the reservation in the api then just roll it back right away | |
| 22:54:05 | mriedem | we'd be smarter to just not create the reservations in the first place if it's soft delete | |
| 22:54:20 | mriedem | but i'm sure that was fixed as a bolt-on bug fix to the already 30 bolt-ons to the local delete code | |
| 22:54:28 | melwitt | yeah, for real | |
| 22:56:14 | mriedem | ok so maybe rather than me spending time making quotas.commit/rollback fail instead of noop if there are no reservations, because of counting quotas removing all of that in master, i can just work on the functional regression test recreate and the fix since those have to be backported to ocata | |
| 22:56:55 | openstack | Launchpad bug 1675570 in OpenStack Compute (nova) "Volumes are not detached when deleting shelved offloaded servers" [High,In progress] - Assigned to Zhenyu Zheng (zhengzhenyu) | |
| 22:56:55 | mriedem | i wanted to fix this before https://bugs.launchpad.net/nova/+bug/1675570 | |
| 22:58:13 | melwitt | yeah. I wonder if some of that will get consolidated bc of the need to call _local_delete in some cases | |
| 22:58:23 | mriedem | that's my plan | |
| 22:58:34 | mriedem | rather than duplicate/triplicate everything, just re-use _local_delete | |
| 22:58:37 | mriedem | for the latter bug | |
| 22:59:15 | melwitt | _local_delete is needed if the instance had ever been scheduled. which you can't tell from only instance.host bc of shelved offloaded I guess | |
| 23:00:04 | melwitt | the other case (the 5-time-reverted patch I have up) is an instance in error state. it could have volumes attached even though it has instance.host = None | |
| 23:00:34 | melwitt | because there's code in compute that resets instance.host to None when setting to ERROR state | |
| 23:00:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Make quotas.commit/rollback strict https://review.openstack.org/452346 | |