Open Stack

Hello,

In my organization, we evaluated a PoC of OpenStack on Kubernetes [01].
As the next step, we are looking to adopt an open solution.

* How do you expect operations on day one to be performed?

Currently, we integrate our own DBaaS for backend db of OpenStack.
In terms of UX, we would be great if such a configuration could be deployed
by similar operations as all-in-one configuration.

I guess Open Services Broker[02] might be the right way to do that.

* How much do you need or want to be able to modify the output we produce to meet your organization's specific requirements?

SDN is going to be a key component for expanding our cluster. We are looking to
evolve scalability by using ODL, OVN, Calico, Contrail or something.

* How do you expect to interact with your deployment, and perform day 2 operations.

The technical specification[7] seems to be fit in our environments so far.

[01] http://blog.kubernetes.io/2016/10/kubernetes-and-openstack-at-yahoo-japan.html
[02] https://www.openservicebrokerapi.org

Regards,
--
Takashi Sogabe

-----Original Message-----
From: Pete Birley [mailto:pete at port.direct] 
Sent: Thursday, December 15, 2016 1:25 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][kolla-kubernetes] Call for Kolla-kubernetes use cases contribution

duonghq,

Thanks for kicking this process off, it really fits in with the point was raising about us needing to define the user experience that we are looking to get with Kolla Kubernetes. However, I think before we jump straight into composing a document on gerrit it may make morse sense to have the initial discussion here?

>From my perspective, the project has really taken off on the development front since Barcelona, with several new contributors, including myself having jumped on board. In my opinion, this project has a huge amount of potential for OpenStack, and Kubernetes alike, as we aim to provide the building blocks that make it easy to consume OpenStack services in harmony with the Kubernetes ecosystem.

I believe that Kolla was originally intended to use Kubernetes to provide OpenStack services, but instead, moved towards a more operator-friendly Ansible model as at the time the feature set that Kubernetes provided was not sufficient to enable OpenStack operation without serious compromise. Since then Kubernetes has come on leaps and bounds and in addition to the Kolla-Kubernetes effort, several other projects have appeared including Stackinetes[1], SAPCC OpenStack Helm[2], AIC-Helm[3], and my own much smaller Harbor[4]. Each of these has implemented OpenStack above Kubernetes in different ways, each with merits and detractors, to meet the needs of their operators and users. It's also worth noting the Hypernetes[5] project that took a vastly different tack and built a Kuberentes distribution that utilized OpenStack services to provide multi-tenancy.

In Barcelona is was decided that we (Kolla-Kubernetes), would move from the original proprietary Jinja2 templating engine, to adopt the Helm[6] tooling from Kubernetes to package OpenStack services. Helm is also being used by both SAPCC OpenStack Helm, and AIC-Helm, to meet their organization's needs.

There has been great progress on making this transition, taking the original templates and converting them into individual Helm charts[6], using a build methodology that we developed to facilitate this conversion. This has meant that we have been able to make the transition with no loss of service continuity but means that we are probably not taking full advantage of the tooling that is now available from our upstream vendor (Kubernetes).

This last point has become a point of contention at times within the development team as we charge full tilt into developing technical solutions following a technical specification[7] written to solve a problem that, it is apparent to me at least, is not as well defined as it could be. Leading to differing options to the direction we should move in, though we all broadly share the same goals. As a result of this, I would really appreciate it if we could spend a short amount of time, most likely via this thread in the mailing list, trying to define the experience we want our users to have (UX). I feel that if this activity is going to be worthwhile it is really important that for a minute we step back from discussing technical detail but define the experience that we want our users to have.

It is also vital that we look to build bridges with the wider OpenStack, and Kubernetes community for this project to be successful, as we are so heavily invested in the tools they provide us with, and we can mutually benefit from the with the experience that we both have in terms of infrastructure lifecycle management.

I am also aware that there have been efforts in the past for groups to get involved in Kolla-Kubernetes that have been unsuccessful. This has been either because they have not been able to adapt to the OpenStack way of working or, and much more concerningly because they have felt significant resistance to their input, of which I myself have certainly been guilty (eg Stackinetes kubernetes-entrypoint). This potentially explains the number of projects that have a similar aim that has sprung up outside of the OpenStack governance, and we should try to learn as much from them as possible: why they exist, what use-case they serve, and if it is possible for us to meet those aims and collaborate in a way that is beneficial for both parties.

I personally feel that we should adopt Kubernetes tooling as much as possible. Fuel-CCP[9], which is also under OpenStack Governance is a project that utilises Kubernetes, but with their own tooling around it, and I don't think that we should be looking to provide an alternate, and potentially competing, implementation of this approach if we are to be widely useful to a large number of stakeholders.

I was planning on taking on the work in the blueprint[8] that Brandon
(v1k0d3n) has proposed, though if you would like to take this on it would be fantastic. I think this is particularly important at this juncture as we begin the process of creating service layer components[10] for Kolla-Kubernetes from the Microservice packages we have produced.

I think that potentially the best way to get the ball rolling would be for everyone who is interested in Kolla-Kubernetes, to specify how you would like to consume Kolla-Kubernetes and how you expect the project to 'feel' in use?

To provide some assistance in this I've prepared a set of bullet points of things to potentially consider, though this should not be viewed a prescriptive set of points by any means:

* How do you expect operations on day one to be performed?

* How much do you need or want to be able to modify the output we produce to meet your organization's specific requirements?

* How do you expect to interact with your deployment, and perform day
2 operations.

This exercise should not be a long and arduous process but should enable us to move much more quickly in future toward producing a cohesive set of building blocks that work for every member of the community, and additionally, move the ecosystem as a whole further forward.

Cheers

Pete (portdirect)

[1] https://github.com/stackanetes/stackanetes#stackanetes
[2] https://github.com/sapcc/openstack-helm#openstack-helm
[3] https://github.com/att-comdev/aic-helm#aic-helm
[4] https://github.com/portdirect/harbor#harbor
[5] https://github.com/hyperhq/hypernetes#what-is-hypernetes
[6] https://github.com/kubernetes/helm#kubernetes-helm
[7] https://github.com/openstack/kolla-kubernetes/blob/master/specs/kolla-kubernetes-arch.rst
[8] https://blueprints.launchpad.net/kolla-kubernetes/+spec/installation-docs-refactor
[9] https://github.com/openstack/fuel-ccp#ccp-overview
[10] https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-services

On Thu, Dec 15, 2016 at 3:43 AM, duonghq at vn.fujitsu.com <duonghq at vn.fujitsu.com> wrote:
> Dear Kollish,
>
> As consensus from last weekly meeting [1], we need to define use cases 
> for kolla-kubernetes, so we can have more concrete ideas about what we should do next for Ocata cycle and next cycles.
>
> After discussed on IRC [2], I created a patchset [3] for tracking use 
> cases evolving. If you have ideas, please submit or comment to this patchset.
>
> [1] 
> http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-12-14-16
> .00.log.html [2] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack
> -kolla.2016-12-15.log.html#t2016-12-15T02:48:07
> [3] https://review.openstack.org/#/c/411043/
>
>
> Thank you,
>
> duonghq
> PODC - Fujitsu Vietnam Ltd.
>
>
>
> ______________________________________________________________________
> ____ 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



--
Pete Birley / Director
pete at port.direct / +447446862551

PORT.DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Port.direct is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

__________________________________________________________________________
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