On 05/03/2016 10:34 AM, Steven Hardy wrote: > Hi all, > > Some folks have requested a summary of our summit sessions, as has been > provided for some other projects. > > I'll probably go into more detail on some of these topics either via > subsequent more focussed threads an/or some blog posts but what follows is > an overview of our summit sessions[1] with notable actions or decisions > highlighted. I'm including some of my own thoughts and conclusions, folks > are welcome/encouraged to follow up with their own clarifications or > different perspectives :) > > TripleO had a total of 5 sessions in Austin I'll cover them one-by-one: > > ------------------------------------- > Upgrades - current status and roadmap > ------------------------------------- > > In this session we discussed the current state of upgrades - initial > support for full major version upgrades has been implemented, but the > implementation is monolithic, highly coupled to pacemaker, and inflexible > with regard to third-party extraconfig changes. > > The main outcomes were that we will add support for more granular > definition of the upgrade lifecycle to the new composable services format, > and that we will explore moving towards the proposed lightweight HA > architecture to reduce the need for so much pacemaker specific logic. > > We also agreed that investigating use of mistral to drive upgrade workflows > was a good idea - currently we have a mixture of scripts combined with Heat > to drive the upgrade process, and some refactoring into discrete mistral > workflows may provide a more maintainable solution. Potential for using > the existing SoftwareDeployment approach directly via mistral (outside of > the heat templates) was also discussed as something to be further > investigated and prototyped. > > We also touched on the CI implications of upgrades - we've got an upgrades > job now, but we need to ensure coverage of full release-to-release upgrades > (not just commit to commit). > > ------------------------------- > Containerization status/roadmap > ------------------------------- > > In this session we discussed the current status of containers in TripleO > (which is to say, the container based compute node which deploys containers > via Heat onto an an Atomic host node that is also deployed via Heat), and > what strategy is most appropriate to achieve a fully containerized TripleO > deployment. > > Several folks from Kolla participated in the session, and there was > significant focus on where work may happen such that further collaboration > between communities is possible. To some extent this discussion on where > (as opposed to how) proved a distraction and prevented much discussion on > supportable architectural implementation for TripleO, thus what follows is > mostly my perspective on the issues that exist: > > Significant uncertainty exists wrt integration between Kolla and TripleO - > there's largely consensus that we want to consume the container images > defined by the Kolla community, but much less agreement that we can > feasably switch to the ansible-orchestrated deployment/config flow > supported by Kolla without breaking many of our primary operator interfaces > in a fundamentally unacceptable way, for example: > > - The Mistral based API is being implemented on the expectation that the > primary interface to TripleO deployments is a parameters schema exposed > by a series of Heat templates - this is no longer true in a "split stack" > model where we have to hand off to an alternate service orchestration tool. > > - The tripleo-ui (based on the Mistral based API) consumes heat parameter > schema to build it's UI, and Ansible doesn't support the necessary > parameter schema definition (such as types and descriptions) to enable > this pattern to be replicated. Ansible also doesn't provide a HTTP API, > so we'd still have to maintain and API surface for the (non python) UI to > consume. > > We also discussed ideas around integration with kubernetes (a hot topic on > the Kolla track this summit), but again this proved inconclusive beyond > that yes someone should try developing a PoC to stimulate further > discussion. Again, significant challenges exist: > > - We still need to maintain the Heat parameter interfaces for the API/UI, > and there is also a strong preference to maintain puppet as a tool for > generating service configuration (so that existing operator integrations > via puppet continue to function) - this is a barrier to directly > consuming the kolla-kubernetes effort directly. > > - A COE layer like kubernetes is a poor fit for deployments where operators > require strict control of service placement (e.g exactly which nodes a > service > runs on, IP address assignments to specific nodes etc) - this is already > a strong requirement for TripleO users and we need to figure out if/how > it's possible to control container placement per node/namespace. > > - There are several uncertainties regarding the HA architecture, such as > how do we achieve fencing for nodes (which is currently provided via > pacemaker), in particular the HA model for real production deployments > via kubernetes for stateful services such as rabbit/galera is unclear. > > Overall a session with much discussion, but further prototyping and > discussion is required before we can define a definitive implementation > strategy (several folks are offering to be involved in this). > > --------------------------------------------- > Work session (Composable Services and beyond) > --------------------------------------------- > > In this session we discussed the status of the currently in-progress work > to decompose our monolithic manifests into per-service profiles[3] in > puppet-tripleo, then consume these profiles via per-service templates in > tripleo-heat-templates[4][5], and potential further work to enable fully > composable (including user defined) roles. > > Overall there was agreement that the composable services work and puppet > refactoring are going well, but that we need to improve velocity and get > more reviewers helping to land the changes. There was also agreement that > a sub-team should form temporarily to drive the remaining work[6], that > we should not land any new features in the "old" template architecture and > relatedly that tripleo cores should help rebase and convert currently > under-review changes to the new format where needed to ease the transition. > > I described a possible approach to providing fully composable roles that > uses some template pre-processing (via jinja2)[7], a blueprint and initial > implementation will be posted soon, but overall the response was positive, > and it may provide a workable path to fully composable roles that won't > break upgrades of existing deployments. > > --------------------------------- > Work session (API and TripleO UI) > --------------------------------- > > In this session we disccussed the current status of the TripleO UI, and the > Mistral based API implementation it depends on. > > Overall it's clear there is a lot of good progress in this area, but there > are some key areas which require focus and additional work to enable a > fully functional upstream TripleO UI: > > - The undercloud requires some configuration changes to enable the UI > necessary access to the undercloud services > > - The UI currently depends on the previous prototype API implementation, > and must be converted to the new Mistral based API (in-progress) > > - We need to improve velocity of the Mistral based implementation (need > more testing and reviewing), such that we can land it and folks can start > integrating with it. > > - There was agreement that the previously proposed validation API can be > implemented as another Mistral action, which will provide a way to run > validation related to the undercloud configuration/state. > > - There are some features we could add to Heat which would make > implementation cleaner (description/metadata in environment files, enable > multiple parameter groups. > > The session concluded with some discussion around the requirements related > to network configuration. Currently the templates offer considerable > flexibility in this regard, and we need to decide how this is surfaced via > the API such that it's easily consumable via TripleO Ux interfaces. > > ----------------------------------- > Work session (Reducing the CI pain) > ----------------------------------- > > This session covered a few topics, but mostly ended up focussed on the > debate with infra regarding moving to 3rd party CI. There are arguments on > both sides here, and I'll perhaps let derekh or dprince reply with a more > detailed discussion of them, but suffice to say there wasn't a clear > conclusion, and discussion is ongoing. > > The other output from this session was agreement that we'd move our jobs to > a different cloud (managed by the RDO community) ahead of a planned > relocation of our current hardware. This has advantages in terms of > maintenance overhead, and if it all goes well we can contribute our > hardware to this cloud long term vs maintaining our own infrastructure. > > > Overall it was an excellent week, and I thank all the session participants > for their input and discussion. Further notes can be found in the > etherpads linked from [1] but feel free to reply if specific items require > clarification (and/or I've missed anything!) > > Thanks, > > Steve > > [1] https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#TripleO > [2] https://review.openstack.org/#/c/299628/ > [3] https://blueprints.launchpad.net/tripleo/+spec/refactor-puppet-manifests > [4] > https://blueprints.launchpad.net/tripleo/+spec/composable-services-within-roles > [5] https://etherpad.openstack.org/p/tripleo-composable-roles-work > [6] http://lists.openstack.org/pipermail/openstack-dev/2016-April/093533.html > [7] http://paste.fedoraproject.org/360836/87416814/ > > __________________________________________________________________________ > 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 > Thanks Steve for the really awesome write-up. Much of what I read here seems to have been bubbling up recently so it's nice to see it getting the attention it deserves.
Thanks, Jason -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen __________________________________________________________________________ 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
