Open Stack

On 9/9/2016 2:08 PM, Mooney, Sean K wrote:
>
>> -----Original Message-----
>> From: Mark Casey [mailto:markcasey at pointofrental.com]
>> Sent: Thursday, September 8, 2016 7:38 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [poll][kolla] Name of baremetal role/group
>>
>> 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.
> [Mooney, Sean K] I think the topic here has drifted from what I originally want
> To capture in this thread but I still find this interesting.
>
> What I was original asking if we should change was the name of the group
> In the multimode inventory
> https://github.com/openstack/kolla/blob/99897c5438f59b3fa40ade388e0eafe6a0fbfffb/ansible/inventory/multinode#L30
> And the corresponding ansible role name.
> https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
>
> this would no be exposed to the enduser at all and was just a question of internal naming
> of the role/group given that the term baremetal may be confused with ironic or bifrost.

Bah, I'm sorry. I too was thinking this was the name of the subcommand 
for kolla-ansible and not just the role and group name. The 
"kolla-ansible bootstrap-servers" you mentioned in another message in 
this thread is an excellent choice for what I thought we were talking 
about. I think the topic drift was mostly a consequence of that 
misunderstanding.

>> 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)
> [Mooney, Sean K] really I have been using kolla for a while now and I did not
> Even know there was a vagrant file. even if I did know it was there it would
> Be the last thing I would ever think of reading as documentation the quickstart
> Guide and other documentation we have is much more useful. Vagrant certenly would
> Not be my first choice when introducing some new to kolla. you don’t want to have to
> Learn another workflow e.g. vagrats when you are trying to wrap your head around ansible,jinja and docker.

You make a good point and you're hardly alone, but I think the other 
group is sizable too. The most common advice I hear is to start with an 
AIO kolla deploy which indirectly requires either setting up a physical 
box, manually configuring a VM and installing with an ISO, or just 
running vagrant up (or maybe a fourth option of running it in an 
existing cloud).

In general vagrant has probably seen some decline but it's still really 
popular and its users are accustomed to checking for it. A quick search 
found official vagrant resources for Kubernetes, Mantl, Elasticsearch, 
Openshift, and even a Devstack variant to make multinode easier (and in 
the past, it was also one of very few methods that were officially 
recommended for running a docker-host VM when not on Linux). Since it 
creates a working deploy from a stock Linux VM it can almost be read as 
a user manual, and because it does it both aio and multinode I found it 
really helpful to see where some of the knobs are in kolla when I started.

>
> [Mooney, Sean K] > 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.
> [Mooney, Sean K] yes this was a separate topic which Is already tracked by
> https://bugs.launchpad.net/kolla/+bug/1616221
Very cool.

Thank you,
Mark

>> 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/baremeta
>>>> l
>>>>
>>>> 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
>>
>> _______________________________________________________________________
>> ___
>> 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