Open Stack

On Mon, 2022-07-11 at 12:18 +0200, Manuel Bentele wrote:
> Hi all,
> 
> I have two general developer questions:
> 
>   * Where are the blueprints and specs located that address changes
>     across the code base?
in generall we create "sibling specs" in each project when we have
cross project work. its rare that we have more then 2 or 3 projects that take part
in any one feature or change so we dont have a singel repo for specs across all
repos.

the close thing we have to that is a a TC selected cross porject goal.
but even then while the goal document might be held locally we would still
track any work on that goal within each proejct.
>   * How to deal with changes that have dependencies on multiple
>     repositories (where a specific merge and release order needs to be
>     satisfied)? 
> 
zuul (or ci/gating system) support cross repo dependiceis and speculitive merging
for testing via "Depends-On:" lines in the commit message.

That will prevent a patch on project A form merging until the patch it depens on in project
B is merged however for testing if you are using the devstack jobs it will locally merge
the patch to proejct B when testing the patch to project A.

this is generaly refered to as co-gatating.

To enable this the jobs have to declare the other project as a required-project
which will resutl in zuul prepareing a version fo the git repo with all depencies merged
which the jobs can then use instead of the current top of the master branch when testing.

the simple tox based unit tests do not support using deps form git. they install
from pypi so unit/functional tests will not pass until a change in a lib is merged
but the integration jobs such as the devstack ones will work.

in general however, out side of constantats and data structure taht are part of the
lib api if project A depens on project B, the Project A should mock all calls to B in
its unit tests and provide a testfixture for B in its functional tests where that
is resonable if they want to mitigate the dependicty issues.
> For example: An enumeration member has to be added and
>     merged in repository A before it can be used in repository B and C.
>     If this order is not satisfied, a DevStack setup may break.
yes which is a good thing. we want devstack to brake in this case since the
set of code you are deploying is broken. but for a ci perspecitve depend-on
prevents this form happening.

for local developemnt you can override the branches used and can tell devstack
to deploy specific patch reviiosn form gerrit or spicic git sha's/branches
via usign the <project>_repo and <project>_branch vars that you can define in
the local.conf.
look at the stackrc file for examples.

> 
> Regards,
> Manuel
> 
>