Open Stack

On 9/8/2016 2:21 AM, Martin André wrote:
> On Wed, Sep 7, 2016 at 11:58 PM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>> Sean,
>>
>>
>>
>> I’d recommend deploy-hosts (I assume this is the bootstrap renamed?)
> +1
> I also like deploy-host better than the other proposed names. Can we
> update the poll to include this option?

I have some concern that present-day conversation, operator support, and 
code reviews often refer to the host that will run kolla-ansible as the 
'kolla host' or the 'deploy host'. So I worry this will be very 
ambiguous (i.e.: "your next step is to run deploy-hosts on the 
deployment host to deploy the hosts"). I'd lean more towards terminology 
like "target-prep", "install-node-deps", or similar.

imho this is really an opportunity to be more consistent with these 
terms project-wide or (perhaps more reasonably) just work towards making 
other references match the decision here. We tell a lot of people to 
start with AIO via vagrant and it (the Vagrantfile - likely the defacto 
most-read documentation we have) refers to these as the operator host 
and the nodes, most of the documentation calls them the deployment host 
and either the target nodes or deployment targets, and this change would 
make the name of the step to install dependencies on the nodes/target 
nodes/deployment targets to deploy-host[s] which sounds more like a 
reference to creating multiple instances of the deployment host/operator 
(I know, that's not even a thing).

Obviously you can't control what Kolla users refer to these components 
as when asking for help or etc., but I suspect it may be frustrating for 
them to use different official names as they make their particular 
progression through stages such as AIO vagrant, AIO baremetal, multinode 
in VMs, and multinode baremetal (actually, if you're having to read all 
of these sentences more slowly or even twice because I'm using all of 
the common terms in all contexts - *that*).  :D


>> I’d also add a duplicate API of “deploy” and mark deploy as deprecated and
>> follow the standard deprecation policies.  I’d recommend making the new
>> OpenStack specific deploy command deploy-openstack
> Agreed.
>
> Martin

I think I'm lost on this part. Does 'deploy'/deploy command here refer 
to 'kolla-ansible deploy' or something else entirely? AFAIK that is 
still a wholly separate step, unless we were just trying to make it 
consistent with the role rename at hand.

Thank you,
Mark

>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>> From: "sean.k.mooney at intel.com" <sean.k.mooney at intel.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Wednesday, September 7, 2016 at 11:51 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [poll][kolla] Name of baremetal role/group
>>
>>
>>
>> Hi
>>
>> I recently introduced a new baremetal role/group which is used as part of
>> the kolla-host playbook.
>>
>> https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
>>
>> This baremetal role is used to install all the dependencies required to
>> deploy kolla containers on a “baremetal” host.
>>
>> The host does not have to be baremetal it can be a vm but the term baremetal
>> was originally chosen as unlike other rules in
>>
>> Kolla it installs and configures packages on the host os.
>>
>>
>>
>> Given that kolla also has baremetal as a service via ironic and baremetal
>> provision of servers with bifrost the question I would like
>>
>> To ask is should we change the name of the current role to install the kolla
>> dependencies to something else.
>>
>>
>>
>> I have created a strawpoll link for this here
>> http://www.strawpoll.me/11175159
>>
>> The options available in the strawpool are:
>>
>> ·         kolla-host
>>
>> ·         host
>>
>> ·         baremetal
>>
>> ·         pre-install
>>
>> If there are any other suggestions fell free to discuss them in this thread.
>>
>> I will check the poll Friday evening gmt and submit a patch for review if
>> consensus is that it should be changed.
>>
>>
>>
>> Regards
>>
>> Sean.
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev