settingsLogin | Registersettings

[openstack-dev] [Nova] Privsep transition state of play

0 votes

Greetings,

I hope everyone travelling to the Sydney Summit is enjoying jet lag just as
much as I normally do. Revenge is sweet! My big advice is that caffeine is
your friend, and to not lick any of the wildlife.

On a more serious note, I want to give a checkpoint for the Nova privsep
transition in the hope that we can discuss it a bit more at the Forum /
Summit / whatever the thing in Sydney with developers is called [1].

As of just now, all rootwrap usage has been removed from the libvirt
driver, if you assume that the outstanding patches from the blueprint are
merged. I think that's a pretty cool milestone. That said, I feel that
https://review.openstack.org/#/c/517516/ needs a short talk to make sure
that people don't think the implementation approach I've taken is confusing
-- basically not all methods in nova/privsep are now escalated, as
sometimes we only sometimes escalate our privs for a call. The review makes
it clearer than I can in an email.

We could stop now for Queens if we wanted -- we originally said we'd land
things early to let them stabilise. That said, we haven't actually caused
any stability problems so far -- just a few out of tree drivers having to
play catchup. So we could also go all in and get this thing done fully in
Queens.

So where to from here?

Michael

1: Its possibly called a pub.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 6, 2017 in openstack-dev by Michael_Still (16,180 points)   3 5 13

2 Responses

0 votes

I hope everyone travelling to the Sydney Summit is enjoying jet lag
just as much as I normally do. Revenge is sweet! My big advice is that
caffeine is your friend, and to not lick any of the wildlife.

I wasn't planning on licking any of it, but thanks for the warning.

As of just now, all rootwrap usage has been removed from the libvirt
driver, if you assume that the outstanding patches from the blueprint
are merged. I think that's a pretty cool milestone. That said, I feel
that https://review.openstack.org/#/c/517516/ needs a short talk to
make sure that people don't think the implementation approach I've
taken is confusing -- basically not all methods in nova/privsep are
now escalated, as sometimes we only sometimes escalate our privs for a
call. The review makes it clearer than I can in an email.

I commented, agreeing with gibi. Make the exceptional cases
exceptionally named; assume non-exceptional names are escalated by
default.

We could stop now for Queens if we wanted -- we originally said we'd
land things early to let them stabilise. That said, we haven't
actually caused any stability problems so far -- just a few out of
tree drivers having to play catchup. So we could also go all in and
get this thing done fully in Queens.

I agree we should steam ahead. I don't really want to hang the fate of
the privsep transition on the removal of cellsv2 and nova-network, so
personally I'm not opposed to privsepping those bits if you're
willing. I also agree that the lack of breakage thus far should give us
more confidence that we're safe to continue applying these changes later
in the cycle. Just MHO.

--Dan


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 6, 2017 by Dan_Smith (9,860 points)   1 2 4
0 votes

On Mon, Nov 6, 2017 at 1:26 PM, Dan Smith dms@danplanet.com wrote:

I hope everyone travelling to the Sydney Summit is enjoying jet lag
just as much as I normally do. Revenge is sweet! My big advice is that
caffeine is your friend, and to not lick any of the wildlife.

I wasn't planning on licking any of it, but thanks for the warning.

You're welcome.

As of just now, all rootwrap usage has been removed from the libvirt
driver, if you assume that the outstanding patches from the blueprint
are merged. I think that's a pretty cool milestone. That said, I feel
that https://review.openstack.org/#/c/517516/ needs a short talk to
make sure that people don't think the implementation approach I've
taken is confusing -- basically not all methods in nova/privsep are
now escalated, as sometimes we only sometimes escalate our privs for a
call. The review makes it clearer than I can in an email.

I commented, agreeing with gibi. Make the exceptional cases
exceptionally named; assume non-exceptional names are escalated by
default.

Ok. I'm struggling to come up with a single word which means "unescalated
unless you're already escalated", but I'll keep pondering.

We could stop now for Queens if we wanted -- we originally said we'd
land things early to let them stabilise. That said, we haven't
actually caused any stability problems so far -- just a few out of
tree drivers having to play catchup. So we could also go all in and
get this thing done fully in Queens.

I agree we should steam ahead. I don't really want to hang the fate of
the privsep transition on the removal of cellsv2 and nova-network, so
personally I'm not opposed to privsepping those bits if you're
willing. I also agree that the lack of breakage thus far should give us
more confidence that we're safe to continue applying these changes later
in the cycle. Just MHO.

I shall prepare the relevant patches then, and look forward to once again
breaking the gate.

Michael


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 6, 2017 by Michael_Still (16,180 points)   3 5 13
...