Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Thierry Carrez]

Davanum Srinivas wrote:
> Clint,
> 
> Pike may be too soon :) as we need to make sure what we have in
> oslo.rootwrap/oslo.privsep work properly in py35. I saw some stuff i
> am still chasing.
> 
> So the one after next will have my vote.

Yes, I'd like us to make enough progress during Pike that people will be
comfortable with it being a Queens goal.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Davanum Srinivas]

Clint,

Pike may be too soon :) as we need to make sure what we have in
oslo.rootwrap/oslo.privsep work properly in py35. I saw some stuff i
am still chasing.

So the one after next will have my vote.

-- Dims

On Thu, Jan 26, 2017 at 9:55 AM, Clint Byrum  wrote:
> Excerpts from Thierry Carrez's message of 2017-01-26 10:08:52 +0100:
>> Michael Still wrote:
>> > I think #3 is the right call for now. The person we had working on
>> > privsep has left the company, and I don't have anyone I could get to
>> > work on this right now. Oh, and we're out of time.
>>
>> Yes, as much as I'm an advocate of privsep adoption, I don't think the
>> last minutes before feature freeze are the best moment to introduce a
>> single isolated privsep-backed command in Nova. So I'd recommend #3.
>>
>> In an ideal world, Nova would start migrating existing commands early in
>> Pike so that in the near future, adding new privsep-backed commands
>> doesn't feel so alien.
>>
>
> Would it be too radical to propose the full migration of everything to
> privsep as a Pike community goal?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2017-01-26 10:08:52 +0100:
> Michael Still wrote:
> > I think #3 is the right call for now. The person we had working on
> > privsep has left the company, and I don't have anyone I could get to
> > work on this right now. Oh, and we're out of time.
> 
> Yes, as much as I'm an advocate of privsep adoption, I don't think the
> last minutes before feature freeze are the best moment to introduce a
> single isolated privsep-backed command in Nova. So I'd recommend #3.
> 
> In an ideal world, Nova would start migrating existing commands early in
> Pike so that in the near future, adding new privsep-backed commands
> doesn't feel so alien.
> 

Would it be too radical to propose the full migration of everything to
privsep as a Pike community goal?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Maxim Nestratov]

26-Jan-17 12:08, Thierry Carrez пишет:


Michael Still wrote:

I think #3 is the right call for now. The person we had working on
privsep has left the company, and I don't have anyone I could get to
work on this right now. Oh, and we're out of time.

Yes, as much as I'm an advocate of privsep adoption, I don't think the
last minutes before feature freeze are the best moment to introduce a
single isolated privsep-backed command in Nova. So I'd recommend #3.

In an ideal world, Nova would start migrating existing commands early in
Pike so that in the near future, adding new privsep-backed commands
doesn't feel so alien.



Yeah, #3 option works for us perfectly, thanks.
Thanks for suggesting it Matt.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Thierry Carrez]

Michael Still wrote:
> I think #3 is the right call for now. The person we had working on
> privsep has left the company, and I don't have anyone I could get to
> work on this right now. Oh, and we're out of time.

Yes, as much as I'm an advocate of privsep adoption, I don't think the
last minutes before feature freeze are the best moment to introduce a
single isolated privsep-backed command in Nova. So I'd recommend #3.

In an ideal world, Nova would start migrating existing commands early in
Pike so that in the near future, adding new privsep-backed commands
doesn't feel so alien.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Michael Still]

I think #3 is the right call for now. The person we had working on privsep
has left the company, and I don't have anyone I could get to work on this
right now. Oh, and we're out of time.

Michael

On Thu, Jan 26, 2017 at 3:49 PM, Matt Riedemann  wrote:

> The patch to add support for ephemeral storage with the Virtuozzo config
> is using the privsep helper from os-brick to run a new ploop command as
> root:
>
> https://review.openstack.org/#/c/312488/
>
> I've objected to this because I'm pretty sure this is not how we intended
> to be using privsep in Nova. The privsep helper in os-brick should be for
> privileged commands that os-brick itself needs to run, and was for things
> that used to have to be carried in both nova and cinder rootwrap filters.
>
> I know we also want new things in nova that require root access to execute
> commands to run privsep, but we haven't had anything do that yet, and we've
> said we'd like an example before making it a hard rule. But we're finding
> it hard to put our foot down on the first one (I remember we allowed
> something in with rootwrap in Newton because we didn't want to block on
> privsep).
>
> With feature freeze coming up tomorrow, however, I'm now torn on how to
> handle this. The options I see are:
>
> 1. Block this until it's properly using privsep in Nova, effectively
> killing it's chances to make Ocata.
>
> 2. Allow the patch as-is with how it's re-using the privsep helper from
> os-brick.
>
> 3. Change the patch to just use rootwrap with a new compute.filters entry,
> no privsep at all - basically how we used to always do this stuff.
>
> In the interest of time, and not seeing anyone standing up to lead the
> charge on privsep conversion in Nova in the immediate future, I'm learning
> toward just doing #3 but wanted to get other opinions.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

[Matt Riedemann]

The patch to add support for ephemeral storage with the Virtuozzo config 
is using the privsep helper from os-brick to run a new ploop command as 
root:


https://review.openstack.org/#/c/312488/

I've objected to this because I'm pretty sure this is not how we 
intended to be using privsep in Nova. The privsep helper in os-brick 
should be for privileged commands that os-brick itself needs to run, and 
was for things that used to have to be carried in both nova and cinder 
rootwrap filters.


I know we also want new things in nova that require root access to 
execute commands to run privsep, but we haven't had anything do that 
yet, and we've said we'd like an example before making it a hard rule. 
But we're finding it hard to put our foot down on the first one (I 
remember we allowed something in with rootwrap in Newton because we 
didn't want to block on privsep).


With feature freeze coming up tomorrow, however, I'm now torn on how to 
handle this. The options I see are:


1. Block this until it's properly using privsep in Nova, effectively 
killing it's chances to make Ocata.


2. Allow the patch as-is with how it's re-using the privsep helper from 
os-brick.


3. Change the patch to just use rootwrap with a new compute.filters 
entry, no privsep at all - basically how we used to always do this stuff.


In the interest of time, and not seeing anyone standing up to lead the 
charge on privsep conversion in Nova in the immediate future, I'm 
learning toward just doing #3 but wanted to get other opinions.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev