Open Stack

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.