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 XenServer specific agent Objections or better suggestions? - Chris On Feb 11, 2011, at 11:48 AM, 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. > > 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 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 +0000, 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 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. >>> >>> >>> 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 mention, we'll need to keep everything in sync, so >>> it feels like it should be a part of nova. :-/ >>> >>> Anyway, since there seems to be a number of opinions that it should be >>> separate, I can do so. We'll just need good documentation on what revs of >>> nova work with what revs of agents. >>> >>> So, that said, any opinions on project names? The current unix agent is >>> 'agent-smith' on LP, but I don't completely like that name and the work I'm >>> doing is significantly modifying the source tree enough that it feels like >>> it's a new project. >>> >>> - Chris >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp