Re: [openstack-dev] [Nova] On idmapshift deprecation

[Matt Riedemann]

On 8/20/2017 3:28 AM, Michael Still wrote:
I'm going to take the general silence on this as permission to remove 
the idmapshift binary from nova. You're welcome.




The reality is that no one is using the LXC code as far as I know. 
Rackspace was the only one ever contributing changes for LXC and we 
never got a CI stood up for it in the gate. So if the changes break 
something, being a Rackspace employee yourself I'd hope you'd find out 
soon enough. So having said that, I think it's fine to go forward with 
removing the binary dependency if you can replace it with privsep.


--

Thanks,

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] On idmapshift deprecation

[Michael Still]

I'm going to take the general silence on this as permission to remove the
idmapshift binary from nova. You're welcome.

Michael

On Sat, Jul 29, 2017 at 10:09 AM, Michael Still  wrote:

> Hi.
>
> I'm working through the process of converting the libvirt driver in Nova
> to privsep with the assistance of Tony Breeds. For various reasons, I
> started with removing all the calls to the chown binary and am replacing
> them with privsep equivalents. You can see this work at:
>
> https://review.openstack.org/#/q/topic:hurrah-for-privsep
>
> The one remaining use of chown in libvirt in that topic is now a tool
> called idmapshift, which is used by the lxc container support to rearrange
> file ownership for filesystems mapped into containers. The tool is a
> separate binary, which the libvirt driver then runs as root.
>
> This binary is relatively easy to replace with python code inside the main
> nova binary in a privsep world -- its basically a refactor with low impact.
> That would be nice because it means we could stop building and shipping an
> extra binary.
>
> However, that binary appears to do a whole bunch of extra things which
> nova itself doesn't use.
>
> So... Do we keep carrying a binary that we wouldn't be using because it
> might be useful to someone? Do you throw away the unused bits of code and
> just refactor the bit we use? Do I bravely run away? If we remove the
> binary, do we do some form of deprecation first? Or because its "internal
> only" just remove it?
>
> Discuss.
>
> Michael
>
__
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] On idmapshift deprecation

[Michael Still]

Hi.

I'm working through the process of converting the libvirt driver in Nova to
privsep with the assistance of Tony Breeds. For various reasons, I started
with removing all the calls to the chown binary and am replacing them with
privsep equivalents. You can see this work at:

https://review.openstack.org/#/q/topic:hurrah-for-privsep

The one remaining use of chown in libvirt in that topic is now a tool
called idmapshift, which is used by the lxc container support to rearrange
file ownership for filesystems mapped into containers. The tool is a
separate binary, which the libvirt driver then runs as root.

This binary is relatively easy to replace with python code inside the main
nova binary in a privsep world -- its basically a refactor with low impact.
That would be nice because it means we could stop building and shipping an
extra binary.

However, that binary appears to do a whole bunch of extra things which nova
itself doesn't use.

So... Do we keep carrying a binary that we wouldn't be using because it
might be useful to someone? Do you throw away the unused bits of code and
just refactor the bit we use? Do I bravely run away? If we remove the
binary, do we do some form of deprecation first? Or because its "internal
only" just remove it?

Discuss.

Michael
__
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