openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

On one hand, I agree it could be separate. This is one of the reasons why
we've waited to push it. Unfortunately, they are so tightly coupled
because it is going to be directly tied to bugfixes in the compute node
that the project leads for each are going to have to keep up with revs of
each agent against a rev of nova. It would seem like the issues between
them would be easier to track if they were all contained in the same
project. 

More below.

On 2/10/11 11:40 AM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:

>On Thu, 10 Feb 2011, Thierry Carrez wrote:
>
>> Paul Voccio wrote:
>> > So the question I want to pose to the community is if they are
>> > interested in the code, where should it go and how should we move
>> > forward on extending it?
>>
>> I think it's always interesting to publish the code. I'm not convinced
>> of the value of shipping it inside Nova though.
>>
>I agree with this.  To me, the agent is a completely separate piece of
>code from nova.  The agent would be able to interact via some
>communication channel with *something*.  That something should not need to
>be openstack.

Right now, that something is Nova. There isn't some external service that
exists yet to do this. If that were the case today, I would just drop it
there. 

>
>I'm not aware of all that your guest agent does, later in this thread,
>configuring networking and setting password was mentioned.  If you ignore
>configuring of initial networking, then its really not tied at all to the
>hypervisor.  

This is precisely our long term goal. How long term is unknown yet.


>I could communicate with an agent that allows setting of root
>password via tcp/ip with that agent running in a guest kvm on my local
>machine.
>
>What I'm getting at, is that I think you should position this as a
>separate project.   Define that openstack supports communication with a
>guest agent via a known protocol that can happen over a list of transports
>(xen store, vmware host-guest link...).   Then, multiple guest agents
>that speak that protocol can arise.

No argument there, but today there are no plans to start on this (that I
know of). If there is momentum to do this, I'd be happy to seed the
project with the code.

>
>Overall, I think it both reduces the complexity of openstack and increases
>the ability for guest OS innovation by clearly defining that boundary.
>
>
>> I'm not in the POC so it's not my job to define what should be
>> considered "Openstack core" and what should not, but "compatible guest
>> agents" IMO typically warrant their own project...
>


pvo



>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.