Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-31
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
23:25:15 nrezinorn How new is the server.create_image snapshot function in nova client/api? I am seeing a problem where randomly the snapshot fails, and the VM stays powered off.
23:28:11 mriedem nrezinorn: probably extremely old
23:28:14 mriedem git blame will tell you
23:28:30 mriedem the client side code shouldn't be causing random issues, you're likely hitting something on the server side
23:28:47 nrezinorn its definately stuff server side, as you can see the errors here
23:28:55 nrezinorn https://gist.github.com/Nrezinorn/decc29d0f142eee34c693e7220090ad9
23:29:29 mriedem qemu is blowing up
23:29:30 nrezinorn ^in that i took a snapshot fine on that VM ~ 20-30 prior and it worked fine
23:29:50 nrezinorn it doesnt always blow up.

Earlier   Later