Open Stack

2014/1/13 Clint Byrum <clint at fewbar.com>:
> 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.

This is a beauty we could have TripleO as official project.
However, this is solution by management.
We should have an architecture for supporting this resource management.

> 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.

I believe existing situation is "Resource management happen inside the
individual projects instead of
 in projects dedicated to working well in this space".

Neutron and nova has db table related with 'host'. (scheduler, agents)
TripleO/Tushar has a resource management table (
I don't know detail of the project, so please correct me if I were wrong here)
Nova-scheduler monitors compute nodes, neutron also monitors agents.
It looks like TripleO/Tushar is planning to monitor nodes.

>People
> would just land features with "FIXME: support config api".

My original proposal won't change config api, so this won't happen.

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev