Open Stack

Hi,

thanks for a write up James. I am adding a few notes/ideas inline...

On Mon, Aug 20, 2018 at 10:48 PM James Slagle <james.slagle at gmail.com>
wrote:

> As we start looking at how TripleO will address next generation deployment
> needs such as Edge, multi-site, and multi-cloud, I'd like to kick off a
> discussion around how TripleO can evolve and adapt to meet these new
> challenges.
>
> What are these challenges? I think the OpenStack Edge Whitepaper does a
> good
> job summarizing some of them:
>
>
> https://www.openstack.org/assets/edge/OpenStack-EdgeWhitepaper-v3-online.pdf
>
> They include:
>
> - management of distributed infrastructure
> - massive scale (thousands instead of hundreds)
> - limited network connectivity
> - isolation of distributed sites
> - orchestration of federated services across multiple sites
>
> We already have a lot of ongoing work that directly or indirectly starts to
> address some of these challenges. That work includes things like
> config-download, split-controlplane, metalsmith integration, validations,
> all-in-one, and standalone.
>
> I laid out some initial ideas in a previous message:
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-July/132398.html
>
> I'll be reviewing some of that here and going into a bit more detail.
>
> These are some of the high level ideas I'd like to see TripleO start to
> address:
>
> - More separation between planning and deploying (likely to be further
> defined
>   in spec discussion). We've had these concepts for a while, but we need
> to do
>   a better job of surfacing them to users as deployments grow in size and
>   complexity.
>

One of the focus points of ui/cli and workflows squads for Stein is getting
GUI and CLI consolidated so
that both clients operate on deployment plan via Mistral workflows. We are
currently working on identifying
missing CLI commands which would lead to adopting the same workflow as GUI
uses. This will lead to
complete interoperability between the clients and would make a deployment
plan the first-class citizen as
Ben mentioned in discussion linked above.

Existing plan import/export functionality makes the deployment plan easily
portable and replicable as it is
possible to export the plan at any point of time and re-use it (with
ability to still
apply some tweaks for each usage)

When Steven's work [1] introduces plan-types which adds ability to define
multiple starting points for the
deployment plan.

[1] https://review.openstack.org/#/c/574753


>
>   With config-download, we can more easily separate the phases of
> rendering,
>   downloading, validating, and applying the configuration. As we increase
> in
>   scale to managing many deployments, we should take advantage of what
> each of
>   those phases offer.
>
>   The separation also makes the deployment more portable, as we should
>   eliminate any restrictions that force the undercloud to be the control
> node
>   applying the configuration.
>
> - Management of multiple deployments from a single undercloud. This is of
>   course already possible today, but we need better docs and polish and
> more
>   testing to flush out any bugs.
>
> - Plan and template management in git.
>
>   This could be an iterative step towards eliminating Swift in the
> undercloud.
>   Swift seemed like a natural choice at the time because it was an existing
>   OpenStack service.  However, I think git would do a better job at
> tracking
>   history and comparing changes and is much more lightweight than Swift.
> We've
>   been managing the config-download directory as a git repo, and I like
> this
>   direction. For now, we are just putting the whole git repo in Swift, but
> I
>   wonder if it makes sense to consider eliminating Swift entirely. We need
> to
>   consider the scale of managing thousands of plans for separate edge
>   deployments.
>
>   I also think this would be a step towards undercloud simplification.
>

+1, we need to identify how much this affects the existing API and overall
user experience
for managing deployment plans. Currentl plan management options we support
are:
- create plan from default files (/usr/share/tht...)
- create/update plan from local directory
- create/update plan by providing tarball
- create/update plan from remote git repository

Ian has been working on similar efforts towards performance improvements
[2], It
would be good to take this a step further and evaluate possibility to
eliminate Swift entirely.

[2] https://review.openstack.org/#/c/581153/

-- Jirka


>
> - Orchestration between plans. I think there's general agreement around
> scaling
>   up the undercloud to be more effective at managing and deploying multiple
>   plans.
>
>   The plans could be different OpenStack deployments potentially sharing
> some
>   resources. Or, they could be deployments of different software stacks
>   (Kubernetes/OpenShift, Ceph, etc).
>
>   We'll need to develop some common interfaces for some basic orchestration
>   between plans. It could include dependencies, ordering, and sharing
> parameter
>   data (such as passwords or connection info). There is already some
> ongoing
>   discussion about some of this work:
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.html
>
>   I would suspect this would start out as collecting specific use cases,
> and
>   then figuring out the right generic interfaces.
>
> - Multiple deployments of a single plan. This could be useful for doing
> many
>   deployments that are all the same. Of course some info might be different
>   such as network IP's, hostnames, and node specific details. We could have
>   some generic input interfaces for those sorts of things without having to
>   create new Heat stacks, which would allow re-using the same plan/stack
> for
>   multiple deployments. When scaling to hundreds/thousands of edge
> deployments
>   this could be really effective at side-stepping managing
> hundreds/thousands
>   of Heat stacks.
>
>   We may also need further separation between a plan and it's deployment
> state
>   to have this modularity.
>
> - Distributed management/application of configuration. Even though the
>   configuration is portable (config-download), we may still want some
>   automation around applying the deployment when not using the undercloud
> as a
>   control node. I think things like ansible-runner or Ansible AWX could
> help
>   here, or perhaps mistral-executor agents, or "mistral as a library". This
>   would also make our workflows more portable.
>
> - New documentation highlighting some or all of the above features and how
> to
>   take advantage of it for new use cases (thousands of edge deployments,
> etc).
>   I see this as a sort of "TripleO Edge Deployment Guide" that would
> highlight
>   how to take advantage of TripleO for Edge/multi-site use cases.
>
> Obviously all the ideas are a lot of work, and not something I think we'll
> complete in a single cycle.
>
> I'd like to pull a squad together focused on Edge/multi-site/multi-cloud
> and
> TripleO. On that note, this squad could also work together with other
> deployment projects that are looking at similar use cases and look to
> collaborate.
>
> If you're interested in working on this squad, I'd see our first tasks as
> being:
>
> - Brainstorming additional ideas to the above
> - Breaking down ideas into actionable specs/blueprints for stein (and
> possibly
>   future releases).
> - Coming up with a consistent message around direction and vision for
> solving
>   these deployment challenges.
> - Bringing together ongoing work that relates to these use cases together
> so
>   that we're all collaborating with shared vision and purpose and we can
> help
>   prioritize reviews/ci/etc.
> - Identifying any discussion items we need to work through in person at the
>   upcoming Denver PTG.
>
> I'm happy to help facilitate the squad. If you have any feedback on these
> ideas
> or would like to join the squad, reply to the thread or sign up in the
> etherpad:
>
> https://etherpad.openstack.org/p/tripleo-edge-squad-status
>
> I'm just referring to the squad as "Edge" for now, but we can also pick a
> cooler owl themed name :).
>
> --
> -- James Slagle
> --
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180822/cfb91f21/attachment.html>