[tripleo] Roadmap to simplify TripleO
Even though TripleO is well known for its maturity, it also has a reputation of being complex when it comes to the number of tools that it uses. Somewhat related to the efforts that James is leading with "Scaling TripleO" [1] [2], I would like to formalize our joint efforts to make TripleO simpler in the future. Some work has been done over the last releases already and yet we have seen net benefits; however we still have challenges ahead of us. - With no UI anymore, do we really need an API? - How can we reduce the number of languages in TripleO? ... and make Python + Ansible the main ones. - How can we reduce our dependencies? I created a document which explains the problems and propose some solutions: https://docs.google.com/document/d/1vY9rsccgp7NHFXpLtCFTHQm14F15Tij7lhn5X_P1... For those who can't or don't want Google Doc, I've put together the notes into etherpad [3] and I'll take care of making sure it's updated at last at the beginning until we sort things out. Feel free to be involved: - comment or suggest edits if you have feedback / ideas - sign-up if you're interested to contribute For now I expect this document to be a clear place what our plan is but I wouldn't be surprised if in the future we break it down into specs / blueprints / etc for better tracking. Thanks, [1] https://docs.google.com/document/d/12tPc4NC5fo8ytGuFZ4DSZXXyzes1x3U7oYz9neaP... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007638.html [3] https://etherpad.openstack.org/p/tripleo-simplification -- Emilien Macchi
Even though TripleO is well known for its maturity, it also has a reputation of being complex when it comes to the number of tools that it uses. Somewhat related to the efforts that James is leading with "Scaling TripleO" [1] [2], I would like to formalize our joint efforts to make TripleO simpler in the future. Some work has been done over the last releases already and yet we have seen net benefits; however we still have challenges ahead of us.
- With no UI anymore, do we really need an API? - How can we reduce the number of languages in TripleO? ... and make Python + Ansible the main ones. - How can we reduce our dependencies?
I created a document which explains the problems and propose some solutions: https://docs.google.com/document/d/1vY9rsccgp7NHFXpLtCFTHQm14F15Tij7lhn5X_P1... For those who can't or don't want Google Doc, I've put together the notes into etherpad [3] and I'll take care of making sure it's updated at last at the beginning until we sort things out.
On 7/11/19 7:52 PM, Emilien Macchi wrote: thanks Emilien, I added a couple of comments in the doc related to two topics which I think have been half-baked in past releases and could be reviewed with the removal of mistral, specifically: - TripleO invocation environment files should not be order dependent - Performing a stack update should not require all original environment files not sure if people familiar with workflows would be interested in helping with these two? -- Giulio Fidente GPG KEY: 08D733BA
On Tue, Jul 23, 2019 at 7:49 AM Giulio Fidente <gfidente@redhat.com> wrote:
On 7/11/19 7:52 PM, Emilien Macchi wrote:
Even though TripleO is well known for its maturity, it also has a reputation of being complex when it comes to the number of tools that it uses. Somewhat related to the efforts that James is leading with "Scaling TripleO" [1] [2], I would like to formalize our joint efforts to make TripleO simpler in the future. Some work has been done over the last releases already and yet we have seen net benefits; however we still have challenges ahead of us.
- With no UI anymore, do we really need an API? - How can we reduce the number of languages in TripleO? ... and make Python + Ansible the main ones. - How can we reduce our dependencies?
I created a document which explains the problems and propose some solutions:
For those who can't or don't want Google Doc, I've put together the notes into etherpad [3] and I'll take care of making sure it's updated at last at the beginning until we sort things out.
https://docs.google.com/document/d/1vY9rsccgp7NHFXpLtCFTHQm14F15Tij7lhn5X_P1... thanks Emilien,
I added a couple of comments in the doc related to two topics which I think have been half-baked in past releases and could be reviewed with the removal of mistral, specifically:
- TripleO invocation environment files should not be order dependent - Performing a stack update should not require all original environment files
not sure if people familiar with workflows would be interested in helping with these two?
I'm happy to help. Maybe we can sync up in IRC this week to discuss the environment ordering. That was a feature we added last year after some discussion.
-- Giulio Fidente GPG KEY: 08D733BA
-- Ryan Brady Senior Software Engineer Red Hat <https://www.redhat.com/> 100 East Davie St. Raleigh, NC 27601 rbrady@redhat.com T: 9198908925 IM: rbrady <https://red.ht/sig>
participants (3)
-
Emilien Macchi
-
Giulio Fidente
-
Ryan Brady