Hi Mark, I started to add few notes and will keep adding as I get more time. The title could perhaps be changed to something more general than multi docker images per project? I’m not sure where to put notes related to versioning – which I think should predate any tooling/workflow/solution discussion. We can use that same wiki page or use a different one.
Thanks Alec From: "Beierl, Mark" <mark.bei...@dell.com> Date: Thursday, July 20, 2017 at 9:19 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com> Cc: Fatih Degirmenci <fde...@gmail.com>, Jose Lausuch <jose.laus...@ericsson.com>, "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>, test-wg <test...@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] OPNFV Docker builds on Dockerhub account Hello, The decision in the Test WG meeting today was to write up our different proposals with pros/cons and take it to the Infra WG for the decision to be made there. I have started a wiki page [1] for review and for everyone to add their ideas and comments. Please edit or mark up the page with your feedback. [1] https://wiki.opnfv.org/display/INF/Multiple+Docker+Images+Per+Project Regards, Mark Mark Beierl SW System Sr Principal Engineer Dell EMC | Office of the CTO mobile +1 613 314 8106<tel:1-613-314-8106> mark.bei...@dell.com<mailto:mark.bei...@dell.com> On Jul 20, 2017, at 11:09, Alec Hothan (ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>> wrote: I second the concerns of Fatih with risk of having to manage 2 paths for building containers if the dockerhup automated build cannot fully satisfy our requirements. Before we make a decision I’d like to suggest that we first iron out our requirements, then it will be easier to make a decision. From: <opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>> on behalf of Fatih Degirmenci <fde...@gmail.com<mailto:fde...@gmail.com>> Date: Wednesday, July 19, 2017 at 7:11 AM To: Jose Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>, "opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" <opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>> Subject: Re: [opnfv-tech-discuss] OPNFV Docker builds on Dockerhub account Hi, It looks nice! Here are some comments. The most important comment I have is the ability to run docker builds for patches as part of verify jobs and post feedback to OPNFV Gerrit. If we go this path, we will have pre-merge builds done on our machines and post-merge builds done on docker hub, which will result in at least same amount of maintenance effort if not more. Also things might result differently due to having 2 different environments where the builds are done. [Alec] you’re touching a very important point which is how do teams verify that their commit “works”. Work could mean “my container builds properly” or could mean “it builds and it runs properly”. Obviously the latter is better but generally requires heavier logistics (such as having a reference openstack pod used for validating containers). I have no idea if OPNFV has that luxury – you tell me as I’m interested as well ;-) In any case we see that there are 2 types of container images: * Those that are used to validate commits only (possibly not as stable as needed for external consumption) * Those that are to be used by external users (presumably in a much more stable state) In the first case, you’re not as committed to keep all built images (it would take way too much space) – in general you just want to keep the last build(s). In the second case you’re pretty much forced to strictly version all images and you need to trace each image version to the exact repo commit. In terms of storage you need to store the last stable images. You don’t need to store all images because you can rebuild them on demand (this is also a benefit of strict versioning). The other comments are the synching, the no of concurrent builds, and the visibility. The synching will definitely slow things down as we need to wait for it to be done. This might be annoying when a crucial bugfix needs to be merged/built. The other possibility is if/when we have issues with synching which might further delay builds. [Alec] can you describe how is the sync (opnfv to github) done today? Method, trigger, frequency? The no of concurrent builds will cause limitations time to time and some builds will have to wait in the dockerhub queue. And finally there will be 2 places to look at for the builds/logs for different things; OPNFV jenkins and docker hub. Also, the synching and concurrent build limit will contribute to the increase in time to get feedback as well. Time to get feedback will increase to time to synch + possible queueing from direct/post-merge triggered builds on our Jenkins. Ps. I will be one of the happy persons if we move to docker hub so I can get rid of maintaining build servers. But I also need to highlight some of the limitations if we do this. [Alec] we will need to get a better idea of the SLA of the dockerhub automated build. Since it is free service I guess it is not guaranteed… Can OPFV live with that (in case of service failure what si plan B)? -- Alec /Fatih On 19 Jul 2017, at 15:30, Jose Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> wrote: Hi, Following up on the discussion about how to build our Docker images, I started a trial with Trevor Bramwell with automated builds on Dockerhub for some of the new Functest Docker images: https://hub.docker.com/r/opnfv/functest-core/builds/ https://hub.docker.com/r/opnfv/functest-smoke/builds/ https://hub.docker.com/r/opnfv/functest-healthcheck/builds/ It triggers a build after the corresponding repository in Github (mirror) has new code. Basically, whenever a new patch is merged on OPNFV gerrit and synched with Github. There is currently a small limitation in the OPNFV Dockerhub account: it can build only 1 image at a time, but we can change that up to 5 or more parallel builds by requesting an account upgrade to LF. You can see the pricing plan here: https://hub.docker.com/account/billing-plans/ We could use this to avoid load on our build servers, use them for something else and of course stop maintaining docker builds in OPNFV. I would like to know your opinion on that. Thanks, Jose _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
