Thanks Ihar, Thierry and Bob. I think we've agreed to go with the 1st option -
"Get Neutron to call XenAPI directly rather than trying to use a daemon".
I will refine the POC patch to make it ready for the formal review.
R.g.t the test, I did some basic test in a real lab manually and it worked
>> Side note: we should first have Xen third-party CI testing running
>
> It already is running
> Oh right. It does not validate the new change though. Would be nice to see
> the new ‘daemon’-ic mode behaves in real world.
100% agreed. I'll work with Jianghua to make sure we get automated
Bob Ball wrote:
Hi Ihar,
I am puzzled. Is Neutron the only component that need to call to dom0?
No it's not. Nova has similar code to call plugins in dom0[1], and
Ceilometer will also need to make the calls for some metrics not exposed
through the formal API.
We
Hi Ihar,
> I am puzzled. Is Neutron the only component that need to call to dom0?
No it's not. Nova has similar code to call plugins in dom0[1], and Ceilometer
will also need to make the calls for some metrics not exposed through the
formal API.
We don't want code duplication, and are
Thierry Carrez wrote:
Bob Ball wrote:
Oslo.privsep seem try to launch a daemon process and set caps for this
daemon; but for XenAPI, there is no need to spawn the daemon.
I guess I'm lacking some context... If you don't need special rights,
why use a
rootwrap-like
Bob Ball wrote:
>>> Oslo.privsep seem try to launch a daemon process and set caps for this
>> daemon; but for XenAPI, there is no need to spawn the daemon.
>>
>> I guess I'm lacking some context... If you don't need special rights, why
>> use a
>> rootwrap-like thing at all ? Why go through a
> > Oslo.privsep seem try to launch a daemon process and set caps for this
> daemon; but for XenAPI, there is no need to spawn the daemon.
>
> I guess I'm lacking some context... If you don't need special rights, why use
> a
> rootwrap-like thing at all ? Why go through a separate process to
Jianghua Wang wrote:
> Is Neutron ready to switch oslo.rootwrap to oslo.privsep?
You'll have to ask neutron-core for an updated status... I think it's
ready, but as I mentioned in my other email the current review
introducing it is currently stalled.
> Oslo.privsep seem try to launch a daemon
Thanks Thierry.
Is Neutron ready to switch oslo.rootwrap to oslo.privsep?
Oslo.privsep seem try to launch a daemon process and set caps for this daemon;
but for XenAPI, there is no need to spawn the daemon. All of the commands to be
executed are sent to the common dom0 XAPI daemon (which will
Ihar Hrachyshka wrote:
> Tony Breeds wrote:
>
>> On Tue, Nov 01, 2016 at 12:45:43PM +0100, Ihar Hrachyshka wrote:
>>
>>> I suggested in the bug and the PoC review that neutron is not the right
>>> project to solve the issue. Seems like oslo.rootwrap is a better
>>> place
Tony Breeds wrote:
On Tue, Nov 01, 2016 at 12:45:43PM +0100, Ihar Hrachyshka wrote:
I suggested in the bug and the PoC review that neutron is not the right
project to solve the issue. Seems like oslo.rootwrap is a better place to
maintain privilege management code
On Tue, Nov 01, 2016 at 12:45:43PM +0100, Ihar Hrachyshka wrote:
> I suggested in the bug and the PoC review that neutron is not the right
> project to solve the issue. Seems like oslo.rootwrap is a better place to
> maintain privilege management code for OpenStack. Ideally, a solution would
> be
Jianghua Wang wrote:
Hi Neutron guys,
I’m trying to explain a problem with the XenServer rootwrap and give a
proposal to resolve it. I need some input on how to proceed with this
proposal: e.g. if requires a spec? Any concerns need further discussion
or
Hi Neutron guys,
I'm trying to explain a problem with the XenServer rootwrap and give a proposal
to resolve it. I need some input on how to proceed with this proposal: e.g. if
requires a spec? Any concerns need further discussion or clarification?
Problem description:
As we've known, some
14 matches
Mail list logo