Open Stack

Hi Sean,

Thanks for you quick and detailed answer. It's good to know that such 
situations are solved with "sibling specs". Also the "Depends-On:" hint 
was very informative for me, especially that this statement can be 
evaluated by the CI/CD chain to prevent it from breaking.

Cheers,
Manuel

On 7/11/22 13:13, Sean Mooney wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220711/46ba8092/attachment.htm>