Scott,
I completely understand your point of view and were you are coming from. I
think you concerns are absolutely valid. That said, there isn't a required
agent feature to do anything yet. We're not designing anything behind any
doors and tossing it over the fence for other people to deal with.
Hi all, I am in firm believe that all network and VM provisioning should
happen outside core via an API to one of possibly many Networking and or
VM Client modules (we are about to release a blueprint for a complete
external network handling module). There can never be full detachment in
the sense
On Fri, 11 Feb 2011, Paul Voccio wrote:
> Below.
>
> On 2/11/11 2:30 PM, "Scott Moser" wrote:
>
> >On Fri, 11 Feb 2011, Vishvananda Ishaya wrote:
> >
> >> Agreed. By default lets put things into nova because it makes
> >> development and visibility much easier. As eric mentioned, we can
> >> al
Below.
On 2/11/11 2:30 PM, "Scott Moser" wrote:
>On Fri, 11 Feb 2011, Vishvananda Ishaya wrote:
>
>> Agreed. By default lets put things into nova because it makes
>> development and visibility much easier. As eric mentioned, we can
>> always break it out later.
>
>The stability of the API for
On Fri, 11 Feb 2011, Vishvananda Ishaya wrote:
> Agreed. By default lets put things into nova because it makes
> development and visibility much easier. As eric mentioned, we can
> always break it out later.
The stability of the API for communication between the hypervisor platform
and an insta
Ok, that sounds good to me. Then, going back to the original path
suggestions, we had:
/tools/guest_agent/unix for the main unix agent code base. Subdirectories
could exist under there for different communication modules (xenstore, etc)
/tools/guest_agent/windows/xen_server for the Windows Xe
Agreed. By default lets put things into nova because it makes development and
visibility much easier. As eric mentioned, we can always break it out later.
Vish
On Feb 11, 2011, at 11:37 AM, Eric Day wrote:
> We can always start this as part of nova for developer convenience
> until the guest
We can always start this as part of nova for developer convenience
until the guest agent APIs stabilize. It's trivial to break this out
into another project later on once other options start to emerge.
-Eric
On Fri, Feb 11, 2011 at 06:51:40PM +, Chris Behrens wrote:
>
> On Feb 11, 2011, at 5
It's required for Rackspace images. It's not necessarily required for others.
You'll need it if you need to configure the VM with a specific IP address and
you're not doing DHCP. It'll be required if you want to offer the ability to
set root password, etc, as well.
- Chris
On Feb 11, 2011,
Tankekontrol
On 2/11/11 12:51 PM, "Chris Behrens" wrote:
>
>On Feb 11, 2011, at 5:53 AM, Paul Voccio wrote:
>
>> 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 directl
On Feb 11, 2011, at 1:51 PM, Chris Behrens wrote:
> Yeah, I'm mixed. I tend to agree with the arguments for keeping it a
> separate project. It makes sense. At the same time, some sort of agent will
> be a requirement for configuring a guest in a non-DHCP based environment.
> And as you men
On Feb 11, 2011, at 5:53 AM, Paul Voccio wrote:
> 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
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
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 con
On Thu, Feb 10, 2011 at 12:08 PM, Chris Behrens
wrote:
> Hi George,
>
> Would love to hear your ideas. I appreciate any conversations that involve
> security and extensibility. :) I have short term goals I need to hit, but
> I'm all for combining any duplicated efforts for the long run.
>
> -
Hi George,
Would love to hear your ideas. I appreciate any conversations that involve
security and extensibility. :) I have short term goals I need to hit, but I'm
all for combining any duplicated efforts for the long run.
- Chris
On Feb 10, 2011, at 8:40 AM, George Reese wrote:
> I have
I have been planning to put together a blueprint proposal for an agent
component leveraging some of the stuff that enStratus has done with agents. The
idea would be for a guest agent that is fully secure and extensible for any
kind of management needs.
Thoughts on combining the efforts?
-Georg
Jay,
It sounds like you understand it. :) The guest agent will be required to
configure the VM's network settings and root password, etc. I share your
thoughts. It feels like it should be a part of nova to me as well.
- Chris
On Feb 10, 2011, at 7:53 AM, Jay Pipes wrote:
> If this guest a
If this guest agent code is going to be required for certain features
in Nova's Cactus release (at least, XenServer features), then
shouldn't it be in Nova?
Or am I not understanding what the guest agent code does?
-jay
On Thu, Feb 10, 2011 at 3:57 AM, Thierry Carrez wrote:
> Paul Voccio 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.
Agree with the directory structure. I'm hoping we can get some
conversation on where to pull the configuration that we use xentore for
now. I've heard some ideas around zookeeper from more than one person, but
have not fully investigated yet.
pvo
On 2/9/11 5:08 PM, "Chris Behrens" wrote:
>
>Tha
Thanks. I was going to pose the same question: where should this go? :)
I'm currently working on the 'xs-guest-agent' blueprint which involves clean up
with the current Rackspace linux agent. While this agent currently only
supports Linux on XenServer (because of some Linux specific calls an
All,
After discussing this among some small groups that are working with XenServer,
we've decided we probably should pull in our guest agent code so others can
look at it and start using it and building on it. Today, this code is XenServer
specific, but long term I think we need to figure out w
23 matches
Mail list logo
