On 9/9/2016 2:08 PM, Mooney, Sean K wrote:
-----Original Message-----
From: Mark Casey [mailto:markca...@pointofrental.com]
Sent: Thursday, September 8, 2016 7:38 PM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@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)
<std...@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.moo...@intel.com" <sean.k.moo...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
<openstack-dev@lists.openstack.org>
Date: Wednesday, September 7, 2016 at 11:51 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@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-requ...@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-requ...@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-
requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
