- Original Message -
> - Original Message -
> > Hi Clayton,
> >
> > Thank you for creating these diagrams. They are a great starting point for
> > discussions
> > around the git deploy blueprint.
> >
> > Some questions/comments:
> >
> > In both the diagrams, what do the arrows i
- Original Message -
> Hi Clayton,
>
> Thank you for creating these diagrams. They are a great starting point for
> discussions
> around the git deploy blueprint.
>
> Some questions/comments:
>
> In both the diagrams, what do the arrows indicate?
> Data flow, control-flow, or some kind
Uri,
Yes. We will need to offer a facility for customizing the CD pipeline(s). We
have not contemplated all of the possibilities for that yet, so this is
something that we will certainly discuss further. We will need to strike the
right balance between options and simplicity.
We have thought t
Hi Adrian
Sounds like there's a need for a true workflow engine here. I suspect that for
any use case beyond trivial, each user will have her own flavor of CD (TripleO
is a good example for this) - some will prefer to use a canary server and test
it manually before deploying to other servers,
ion,
or, build abstraction -> deploy abstraction. What are your thoughts on this?
Best regards,
Devdatta
-Original Message-
From: "Adrian Otto"
Sent: Wednesday, October 30, 2013 8:01pm
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re:
Robert,
We would be interested in exploring your use case for CD, and help you judge
what would be the best fit. I know that Monty Taylor has identified some parts
of openstack-infra that we could potentially leverage in Solum to address our
CI/CD goals. The design of that feature is still pend
Hi Adrian,
I'm very interested in Solum, particularly as it relates to
TripleO : as you know the TripleO story is to treat OpenStack as just
another application to install via Heat/Nova etc - and we've got a
major story around pulling from git -> CI + CD pipeline -> automated
deployment to prod
Clayton,
Thanks for adding the diagram illustrating the flow. I expect that "respond to
client" may not be a synchronous flow, rather that if creation of a repo takes
a while that the API may return a 202 Accepted, and the client can poll a
status attribute to determine completion and learn the
In the IRC meeting yesterday [1] we discussed splitting the individual topics
for the git deploy blueprint [2] into rough sub areas. To help frame the
abstractions we've been discussing I roughed out a flow based on two user
inputs, REST API create and a git push and then tried to draw boxes ar