ONAP components are delivered in a somewhat monolith form, e.g. each container of each application have the same image tag, are never released individually, AFAIK. For instance, when there is a fix for one container, say in SDNC, it’s the all the SDNC containers that get released, same for SO, AAI, etc...
Right now repo structure is somewhat free for all, making thing hard to grasp for new comers, to maintain for PTL, to debug/dev/search for developer, and to release for RelEng. I agree having one repo per container can be ideal in some cases, but reality is currently different. With the number of containers in ONAP, I’m not convinced this is the best path forward. Having one repo per project with CI/CD based on sub-folders of the repo could be also a good answer to address the need (note: SO is *not* an example of that, having one module building all the images, rather than each module building their own). I believe this is a very good discussion for TSC to have, in order to come up with best practices and then having them reflected across projects. > On Jul 8, 2019, at 4:43 AM, Sylvain Desbureaux via Lists.Onap.Org > <sylvain.desbureaux=orange....@lists.onap.org> wrote: > > Hello Krzysztof, > > That exactly was the " we should have a __clear__ (automated) policy on how > to upgrade the upstream components" so we're absolutely inline (. > > --- > Sylvain Desbureaux > > Le 08/07/2019 10:42, « onap-tsc@lists.onap.org au nom de Krzysztof Opasiak > via Lists.Onap.Org » <onap-tsc@lists.onap.org au nom de > k.opasiak=samsung....@lists.onap.org> a écrit : > > > >> On 08.07.2019 10:20, Sylvain Desbureaux via Lists.Onap.Org wrote: >> Hello Kenny, >> >> If I may I think that “micro” repos are a better way to handle code in a >> CI/CD world. Let’s take two examples: >> >> * SO: SO has (roughly) one project into ONAP git but delivers 13 >> containers. That means that 1 code change that should affect only >> one of the containers will rebuild the 13 containers so it’s >> __hard__ to debug at the end. >> * SDC: SDC has 21 repos (if I’m not mistaken) and delivers 13 >> containers also. That mean that 1 code change that should affect >> only one of the containers __should__ rebuild 1 containers. I assume >> that some repos could be merged together but not that much IMHO. >> >> So for me a good practice is: >> >> * This “folder” / code produce 1 container àit should be a project >> into gerrit >> * This “folder” / code is a common foundation for several containers >> àit should be a project into gerrit and we should have a __clear__ >> (automated) policy on how to upgrade the upstream components. > > I strongly agree with your point but I'd like to also add that in order > to fully benefit from multiple repo workflow we should start using > proper tags in gerrit (Depends-On:) if we are doing changes that affect > other repos and learn our CI/CD system to properly interpret that to > avoid fake failures in number of reviews... > > Best regards, > -- > Krzysztof Opasiak > Samsung R&D Institute Poland > Samsung Electronics > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5193): https://lists.onap.org/g/onap-tsc/message/5193 Mute This Topic: https://lists.onap.org/mt/32389899/21656 Group Owner: onap-tsc+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
