Create a dev mode option
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo-quickstart |
Fix Released
|
Medium
|
Attila Darazs |
Bug Description
This is partially discussed in https:/
The key things that need to be handled are:
1. Puppet modules from source
For the undercloud this is easy, as there is already a mechanism to pass arbitrary environment variables to the undercloud install. For the overcloud, I have had success with using the puppet modules from the undercloud via deploy artifacts, but this is not wired in to tripleo-quickstart.
2. Repo setup
We need a way to pass in extra repos, so we can get a repo setup like tripleoci. To start, this would just be a trunk 'current' repo with the whitelisted tripleo packages. However, it would be good if we could use this same mechanism to pass in a delorean repo created on the fly for CI purposes.
3. Some way to conditionally enable the above behaviors
There is a good reason that RDO does not do the above steps. Since we are using HEAD of master of all of tripleo and puppet, it is more fragile. I would like to keep the default path as something that has a very high probability of success at all times. This is obviously what we want for new users, but I think even the dev case benefits from that default. It makes it easy to see if something is unexpectedly broken with the tool itself or with one of the projects it sets up. I think both of the above steps are completely additive to the existing RDO configuration, so we could create a dev.yml configuration that enables those behaviors, and gets used with a --dev option to quickstart.sh.
Changed in tripleo-quickstart: | |
assignee: | John Trowbridge (trown) → Attila Darazs (adarazs) |
I set this as critical, because we will not likely get a non-dev mode promotion of the master repo this week[1], and next week is summit. Without a promotion in RDO, we do not have ANY image on master to consume. That severely limits tripleo- quickstart' s value.
I have a repo hash that will pass with using puppet modules from source (by the time the manual OPM process happened there was some other breakage on trunk), and given that we have no image now, I do think it is a step forward to have an image that only works in dev mode.
[1] For one there are multiple failures to build from source from a new unpackaged dependency, which now blocks moving the pin forward even if we fixed all of the other breakages.