incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <prasanna.santha...@citrix.com>
Subject Re: [Discussion]Auto provision of hosts(hypervisors) into cloud using auto discovery mechanism from the specified IP address range
Date Thu, 25 Oct 2012 13:31:37 GMT
On Tue, Oct 23, 2012 at 12:51:22PM -0400, David Nalley wrote:
> On Tue, Oct 23, 2012 at 12:06 PM, Prasanna Santhanam
> <prasanna.santhanam@citrix.com> wrote:
> > On Tue, Oct 23, 2012 at 12:00:18PM -0400, John Burwell wrote:
> >> David,
> >>
> >> Why not expose an API that would allow Cobbler, Foreman, Razor, etc
> >> to call into CloudStack at the appropriate times?  The current REST
> >> API may even be sufficient.  Speaking with experience using both
> >> Cobbler and Foreman, they work better when they are coordinating the
> >> provisioning activities rather than being embedded into another
> >> system.   It also avoid any licensing issues, and allows customers
> >> to chose the tools that most appropriately fits their environment.
> >>
> >
> > Yup - Foreman comes to mind since it plays well with puppet too during
> > post-install. As a seperate appliance per pod would be best, an image
> > that configures - cobbler/foreman/$your_fav_system as per your
> > physical infrastructure with the admin's REST api of CloudStack.
> 
> Why per pod?

I imagined a pod level switch to be the boundary at which the PXE/DHCP
for the subnet of each pod happens. Since PXE/DHCP which underlies
most of these extended-PXE solutions will not be able to boot hosts in
a different subnet beyond this boundary we'll need to have an instance
per pod. The said appliance would then be sitting on the management
network refreshing the hosts. Either that or allow a multi-homed
appliance with one arm in each pod's subnet to cater to the clusters
within it. The former seems simpler to me.

-- 
Prasanna.,

Mime
View raw message