Open Stack

Excerpts from Nachi Ueno's message of 2014-01-13 10:35:07 -0800:
> Hi Clint
> 
> 2014/1/10 Clint Byrum <clint at fewbar.com>:
> > Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700:
> >> Hi Flavio, Clint
> >>
> >> I agree with you guys.
> >> sorry, may be, I wasn't clear. My opinion is to remove every
> >> configuration in the node,
> >> and every configuration should be done by API from central resource
> >> manager. (nova-api or neturon server etc).
> >>
> >> This is how to add new hosts, in cloudstack, vcenter, and openstack.
> >>
> >> Cloudstack: "Go to web UI, add Host/ID/PW".
> >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html
> >>
> >> vCenter: "Go to vsphere client, Host/ID/PW".
> >> https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html
> >>
> >> Openstack,
> >> - Manual
> >>    - setup mysql connection config, rabbitmq/qpid connection config,
> >> keystone config,, neturon config, xxxx
> >> http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html
> >>
> >> We have some deployment system including chef / puppet / packstack, TripleO
> >> - Chef/Puppet
> >>    Setup chef node
> >>    Add node/ apply role
> >> - Packstack
> >>    -  Generate answer file
> >>       https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html
> >>    -  packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2
> >> - TripleO
> >>    - UnderCloud
> >>        nova baremetal node add
> >>    - OverCloud
> >>        modify heat template
> >>
> >> For residence in this mailing list, Chef/Puppet or third party tool is
> >> easy to use.
> >> However,  I believe they are magical tools to use for many operators.
> >> Furthermore, these development system tend to take time to support
> >> newest release.
> >> so most of users, OpenStack release didn't means it can be usable for them.
> >>
> >> IMO, current way to manage configuration is the cause of this issue.
> >> If we manage everything via API, we can manage cluster by horizon.
> >> Then user can do "go to horizon, just add host".
> >>
> >> It may take time to migrate config to API, so one easy step is to convert
> >> existing config for API resources. This is the purpose of this proposal.
> >>
> >
> > Hi Nachi. What you've described is the vision for TripleO and Tuskar. We
> > do not lag the release. We run CD and will be in the gate "real soon
> > now" so that TripleO should be able to fully deploy Icehouse on Icehouse
> > release day.
> 
> yeah, I'm big fan of TripleO and Tuskar.
> However, may be, it is difficult to let TripleO/Tuskar up-to-dated
> with newest releases.
> 
> so let's say Nova and neutron added new function in 3rd release (I3
> for icehouse),
> there is no way to support it in TripleO/Tuskar.
> This is natural, because TripleO/Tuskar is 3rd party tool for nova or
> neutron. (same as Chef/Puppet).
> IMO, Tuskar API and existing projects(nova, neturon) should be
> integrated in design level.
> 

This is false. TripleO is the official OpenStack deployment program. It
is not a 3rd party tool. Of course sometimes TripleO may lag the same
way Heat may lag other integrated release components. But that is one
reason we have release meetings, blueprints, and summits, so that projects
like Heat and TripleO can be aware of what is landing in i3 and at least
attempt to have some support in place ASAP.

Trying to make this happen inside the individual projects instead of
in projects dedicated to working well in this space is a recipe for
frustration, and I don't believe it would lead to any less lag. People
would just land features with "FIXME: support config api".