Open Stack

-----Original Message-----
From: Hongbin Lu <hongbin.lu at huawei.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: March 21, 2016 at 22:22:01
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [magnum] High Availability

> Tim,
>  
> Thanks for your advice. I respect your point of view and we will definitely encourage  
> our users to try Barbican if they see fits. However, for the sake of Magnum, I think we have  
> to decouple from Barbican at current stage. The coupling of Magnum and Barbican will  
> increase the size of the system by two (1 project -> 2 project), which will significant  
> increase the overall complexities.

Hi Hongbin,

I think you're missing the fact that Tim represents a very large and very visible user of OpenStack, CERN.

> · For developers, it incurs significant overheads on development, quality assurance,  
> and maintenance.

Are you sure? It seems like barbican isn't a common problem among developers. It's more of a problem for operators because the dependency is very poorly documented.

> · For operators, it doubles the amount of efforts of deploying and monitoring the system.  

This makes operators sound a bit ... primitive in how they deploy things. That seems quite unfair. CERN is using Puppet-OpenStack which might need help to improve it's Magnum and Barbican puppet modules, but I doubt this is a big concern for them. People using the new ansible roles will notice similar gaps given their age, but these playbooks transparently provide everything to deploy and monitor the system. It's no more difficult for them to deploy both magnum and barbican than it is to deploy one or the other. I'm sure the Chef OpenStack efforts are also similarly easy to add to an existing OpenStack deployment.

The only people who might have problems with deploying the two in conjunction are people following the install guide and using system packages *only* without automation. I think it's also fair to say that this group of people are not your majority of operators. Further, given the lack of install guide content for magnum, I find it doubtful people are performing magnum installs by hand like this.

Do you have real operator feedback complaining about this or is this a concern you're anticipating?

> · For users, a large system is likely to be unstable and fragile which affects the user  
> experience.
> In my point of view, I would like to minimize the system we are going to ship, so that we can  
> reduce the overheads of maintenance and provides a stable system to our users.

Except you are only shipping Magnum and the Barbican team is shipping Barbican. OpenStack is less stable because it has separate services for the core compute portion. Further, Nova should apparently have its own way of accepting uploads for and managing images as well as block storage management because depending on Glance and Cinder for that is introducing fragility and *potential* instability.

OpenStack relies on other services and their teams of subject matter experts for good reason. It's because no service should manage every last thing itself when another service exists that can and is doing that in a better manner.

> I noticed that there are several suggestions to “force” our users to install Barbican,  
> which I would respectfully disagree. Magnum is a young project and we are struggling  
> to increase the adoption rate. I think we need to be nice to our users, otherwise, they  
> will choose our competitors (there are container service everywhere). Please understand  
> that we are not a mature project, like Nova, who has thousands of users. We really don’t  
> have the power to force our users to do what they don’t like to do.

Why are you attributing all of your adoption issues to needing Barbican? One initial barrier to my evaluation of Magnum was its lack of documentation that is geared towards operators at all. The next barrier was the client claiming it supported Keystone V3 and not actually doing so (which was admittedly easily fixed). Putting all the blame on Barbican is a bit bizarre from my point of view as someone who has and is deploying Magnum.

> I also recognized there are several disagreements from the Barbican team. Per my understanding,  
> most of the complaints are about the re-invention of Barbican equivalent functionality  
> in Magnum. To address that, I am going to propose an idea to achieve the goal without duplicating  
> Barbican. In particular, I suggest to add support for additional authentication system  
> (Keystone in particular) for our Kubernetes bay (potentially for swarm/mesos). As  
> a result, users can specify how to secure their bay’s API endpoint:
>  
> · TLS: This option requires Barbican to be installed for storing the TLS certificates.  

An alternative to this is using ephemeral certificates made by a service like Anchor or Let's Encrypt. This has also been pointed out (and ignored) previously in this thread.

> · Keystone: This option doesn’t require Barbican. Users will use their OpenStack credentials  
> to log into Kubernetes.

This seems perfectly fine but I don't think this should be an alternative to using TLS to talk to Kubernetes. Personally, I want everything to use TLS so if my option is Keystone or TLS, I'm not going to be satisfied.

> I am going to send another ML to describe the details. You are welcome to provide your inputs.  
> Thanks.

I look forward to reading this.

Cheers,
--  
Ian Cordasco