On Thu, Jul 21, 2016 at 5:47 PM, James Slagle <[email protected]> wrote:
> On Tue, Jul 19, 2016 at 5:15 PM, Wesley Hayutin <[email protected]> > wrote: > > > > > > On Tue, Jul 19, 2016 at 2:44 PM, James Slagle <[email protected]> > > wrote: > >> Part of the goal of tripleo.sh was to mirror the commands in the > >> documentation...that the same commands in the docs are in tripleo.sh. > >> I know that has somewhat failed, but it was the goal anyway. > >> > >> Do you think integrating ansible into tripleo-ci changes that at all? > >> tripleo-ci would be using ansible in some places, which in turn runs > >> the commands (or their equivalent) that we actually document. Is the > >> documentation still showing the same commands it does now, or is it > >> showing running ansible as tripleo-ci would be doing? > > > > > > Harry Rybacki and I are working on this now. I think we have something > that > > is reasonable for when shell can be used and when ansible modules are > > required. I think he can make all this work public and everyone in > TripleO > > can keep tabs on the progress. > > Yes, I saw his email shortly after sending my reply. There is a lot to > digest there, but it sounds promising. Perhaps we could start with > something small and iteratively consume the generated docs as well. We > could replace the manual docs over time by including sphinx docs at > the right places that were automatically generated. > Agree, He has a small example project where I think you could track the work and progress. https://github.com/HarryRybacki/tripleo-documentor We're hoping to have the undercloud and overcloud steps templated and built in the very near future. > > > >> > >> > >> I think I'm mostly in agreement with your #2 proposal, perhaps with > >> the exception of having to rely on external roles. I don't think I > >> would want to see tripleo-ci rely on ansible roles from a > >> redhat-openstack organization on github. > >> > >> I know that we already have a lot of external dependencies in TripleO, > >> and that not everything has to come from git.openstack.org. However, I > >> think that we'd want to make the "source" for tripleo-ci be owned by > >> the TripleO project and hosted by OpenStack infrastructure as much as > >> possible. tripleo-quickstart already is, so I think it would be fine > >> to start proposing some changes to tripleo-ci that use > >> tripleo-quickstart to eliminate some duplication if everyone agrees > >> with that. Maybe the repo-setup would be a good first iterative step. > >> > >> As for the external roles, I'm less of a fan of relying on these > >> directly if they're not part of TripleO. I think the project should > >> have ownership over how it's defined in CI to deploy/update/upgrade > >> overclouds, etc. > > > > > > +1 I think this can be handled in a couple ways depending on how many > > additional git repos are acceptable to TripleO upstream. > > > > So maybe if I provide an example this will make more sense. I think bare > > metal will work as an example. > > > > There is a need for the code that drives CI for virt to be able to drive > CI > > for bare metal. Certainly the bare metal use case will not be used > nearly > > as much as the virt workflow and I suspect we don't want code conflicts, > > merge issues coming from the bare metal use case that may interrupt or > block > > the mainline virt use case. I think TripleO still cares what the bare > metal > > code looks like, how it's developed, and if we can use it w/ 3rd party CI > > and extra checks. It's important to maintain bare metal roles in TripleO > > but it's easier if they are in another git repository. It also > > demonstrates the composability of the CI. > > > > Another use case would be anything that may be downstream specific. I > can't > > think of a great example atm, but there are use cases that CI should be > able > > to drive that will probably never be part of the mainstream tripleo ci > jobs. > > > > I believe we can solve this by having just two git repos in the long > run. I > > think one git repo would be for any code path that is used directly in a > job > > in tripleo-ci itself. The second repo would contain multiple ansible > roles, > > call it tripleo-ci-extras. The second repo would contain any extra roles > > that need to be plugged in for a use case that is not in a tripleo-ci job > > itself. This would allow TripleO to manage and review the code w/o > > impacting the day to day business of tripleo-ci. > > > > Something like: > > > > github.com/openstack/tripleo-ci-extras > > > > /ansible-role-upgrades > > /ansible-role-image-build > > /ansible-role-baremetal-undercloud > > /ansible-role-baremetal-undercloud-post > > /ansible-role-baremetal-overcloud > > /defaults > > /tasks/ > > /templates > > setup.cfg > > > >> > >> Are the roles generic enough that we could propose these as part of > >> TripleO directly as new repos, and is there interest in doing that? > > > > > > That is also a possibility. I think we'd have to take a hard look at > some > > of these roles and determine whether or not it's worth having it's own > git > > repo. > > Most are fairly generic imho. For instance the image-build role can > build > > images for tripleo, rdo, or rhos, the bare metal roles don't have any > > environment specific code they just expect the settings provided to the > job > > to describe the environment in a particular way. The upgrade role can > be > > used for any tripleo version upstream or downstream. > > > > IMHO I think bare metal, upgrades, and image builds would be good > candidates > > for their own upstream git repo. Many of the other roles could be > combined > > in a single git repo to avoid the pain of git repo explosion. I think we > > can work w/ either approach, the most important thing is to start > removing > > the duplication as you said! > > Sure, I don't think this is something we have to decide right away. As > common roles emerge we could hopefully standardize on those, and if it > makes sense to split them out into their own repo at some point, we > could do that to. > Ack and thanks. Have a good night! > > -- > -- James Slagle > -- > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
