On 03/23/2016 04:45 PM, Ian Cordasco wrote:
-----Original Message-----
From: Monty Taylor <mord...@inaugust.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: March 22, 2016 at 18:49:41
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [magnum] Streamline adoption of Magnum
On 03/22/2016 06:27 PM, Kevin Carter wrote:
/me wearing my deployer hat now: Many of my customers and product folks
want Magnum but they also want magnum to be as secure and stable as
possible. If Barbican is the best long term solution for the project it
would make sense to me that Magnum remain on course with Barbican as the
defacto way of deploying in production. IMHO building alternative means
for certificate management is a distraction and will only confuse folks
looking to deploy Magnum into production.
I'm going to agree. This reminds me of people who didn't want to run
keystone back in the day. Those people were a distraction, and placating
them hampered OpenStack's progress by probably several years.
Right. Barbican is a good service that is actually necessary for a cloud (see
also other similar services announced by the likes of Hashicorp). Magnum
relying on it to securely store information makes perfect sense.
Some ops teams are willing to
adopt a new service, but not two. They only want to add Magnum and not
Barbican.
It would seem to me that once the Barbican dependency is well
documented, which it should be at this point, Barbican is be easy to
accept especially with the understanding of why it is needed. Many of
the deployment projects are creating the automation needed to make the
adoption of services simpler and I'd imagine deployment automation is
the largest hurdle to wide spread adoption for both Barbican and Magnum.
If the OPS team you mention does not want both services it would seem
they can use "local file" option; this is similar to Cinder+LVM and
Glance+file_store both of which have scale operational issues in production.
Agree.
If it wasn't obvious, I also agree. That said, people will still try to use
these to avoid the illusion of additional costs. They tend to ignore the cost
of the repercussions of these decisions down the road.
We think that once those operators become familiar with
Magnum, adding Barbican will follow. In the mean time, we’d like to
offer a Barbican alternative that allows Magnum to scale beyond one
conductor, and allows for encrypted storage of TLC credentials needed
for unattended bay operations.
If all of this is to simplify or provide for the developer/"someone
kicking the tires" use case I'd imagine the "local file" storage would
be sufficient. If the acceptance of Barbican is too much to handle or
introduce into an active deployment (I'm not sure why that would be
especially if they're adding Magnum), the synchronization of locally
stored certificates across multiple hosts is manageable and can be
handled by a very long list of other pre-existing operational means.
Right, they may be using any of the other recently announced services created
and provided by other groups.
A blueprint [2] was recently proposed to
address this. We discussed this in our team meeting today [3], where we
used an etherpad [4] to collaborate on options that could be used as
alternatives besides the ones offered today. This thread is not intended
to answer how to make Barbican easier to adopt, but rather how to make
Magnum easier to adopt while keeping Barbican as the default
best-practice choice for certificate storage.
I'd like there _NOT_ to be an "easy button" way for operators to hang
themselves in production by following a set of "quick start
instructions" under the guise of "easy to adopt". If Barbican is the
best-practice lets keep it that way. If for some reason Barbican is hard
to adopt lets identify those difficulties and get them fixed. Going down
the path of NIH or alternative less secure solutions because someone
(not identified here or speaking for themselves) has said they don't
want Barbican or deploying it is hard seems like a recipe for
fragmentation and disaster.
Agree.
Perhaps, if the problem is less that two new services is problematic and the
real problem is one (or some combination) of:
- Magnum and Barbican's dependency is poorly (if at all) documented
- Magnum and Barbican don't have documentation to deploy the services
- Magnum should support a variety of services like Barbican (e.g., adding
support for Vault)
There are things that can be done. One thing is writing documentation. Another
would be a driver for Vault or any other service the community might want.
(Which is not to imply that there is a desire to rely on those, just that those
are services that might be easier for our hypothetical operators to deploy.)
Yah. I'm not crazy about OpenStack services spending much time worrying
about integration with other non-OpenStack services when there is also a
clear OpenStack service ... however, I'd rather see a Vault driver in
Magnum as a vehicle to pain avoidance and not an in-tree barbican-lite.
I'd still rather just declare the dependency and be done with it.
Monty
__________________________________________________________________________
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
