Hi Mark, Yes, there may be some some configuration files or entry point shell file in the sub-directory. We can keep in the same sub-directory and it can be supported well.
Can you list some use case for the docker to contain other files in parents' directory? Maybe it also can be supported during the bootup time. Beierl, Mark <[email protected]>于2017年7月10日周一 上午7:26写道： > My only concern is for dockerfiles that do a "COPY . /home" in them. That > means all the code would be located under the docker directory. > > I suppose multiple ../ paths can be used instead. > > Regards, > Mark > > *Mark Beierl* > SW System Sr Principal Engineer > *Dell **EMC* | Office of the CTO > mobile +1 613 314 8106 <1-613-314-8106> > [email protected] > > On Jul 9, 2017, at 19:03, Julien <[email protected]> wrote: > > Hi Cédric, > > Patch in https://gerrit.opnfv.org/gerrit/#/c/36963/ is exact what I > mean. Let's collect the opinions from the releng team. > > Julien > > > > Cedric OLLIVIER <[email protected]>于2017年7月10日周一 上午4:15写道： > >> Hello, >> >> Please see https://gerrit.opnfv.org/gerrit/#/c/36963/ which introduces >> several containers for Functest too. >> I think the tree conforms with the previous requirements. >> >> Automating builds on Docker Hub is a good solution too. >> >> Cédric >> >> 2017-07-09 12:10 GMT+02:00 Julien <[email protected]>: >> >>> Hi Jose, >>> >>> According to the current implementation, current script only support one >>> Dockerfile, my personal suggestion is: >>> 1. list all the sub-directory which contains "Dockerfile" >>> 2. build for each sub-directory fetched in #1 >>> 3. for the names, in the top directory using the project name, in the >>> sub-directory using: project_name-sub_directory_name >>> not too much changes for current script and easy for project to manage. >>> >>> /Julien >>> >>> Beierl, Mark <[email protected]>于2017年7月7日周五 下午11:35写道： >>> >>>> Hello, >>>> >>>> Having looked over the docker-hub build service, I also think this >>>> might be the better approach. Less code for us to maintain, and the merge >>>> job from OPNFV Jenkins can use the web hook to remotely trigger the job on >>>> docker-hub. >>>> >>>> Who has the opnfv credentials for docker-hub, and the credentials for >>>> the GitHub mirror that can set this up? Is that the LF Helpdesk? >>>> >>>> Regards, >>>> Mark >>>> >>>> *Mark Beierl* >>>> SW System Sr Principal Engineer >>>> *Dell **EMC* | Office of the CTO >>>> mobile +1 613 314 8106 <1-613-314-8106> >>>> [email protected] >>>> >>>> On Jul 7, 2017, at 11:01, Xuan Jia <[email protected]> wrote: >>>> >>>> +1 Using build service from docker-hub >>>> >>>> >>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) < >>>> [email protected]> wrote: >>>> >>>>> Does anybody consider using the build service from docker-hub[1] ? >>>>> >>>>> It supports multiple Dockerfile from same repository and easy to >>>>> integrate with OPNFV Github mirror. >>>>> >>>>> [1]: https://docs.docker.com/docker-hub/builds/ >>>>> >>>>> >>>>> On Thu, Jul 6, 2017 at 11:02 PM Jose Lausuch < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Mark, >>>>>> >>>>>> >>>>>> >>>>>> I would incline for option 1), it sounds better than searching for a >>>>>> file. We could define specific values of DOCKERFILE var for each project. >>>>>> >>>>>> >>>>>> >>>>>> /Jose >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Beierl, Mark [mailto:[email protected]] >>>>>> *Sent:* Thursday, July 06, 2017 16:18 PM >>>>>> *To:* [email protected] >>>>>> *Cc:* Julien <[email protected]>; Fatih Degirmenci < >>>>>> [email protected]>; Jose Lausuch < >>>>>> [email protected]> >>>>>> *Subject:* Re: [opnfv-tech-discuss] Multiple docker containers from >>>>>> one project >>>>>> >>>>>> >>>>>> >>>>>> Ideas: >>>>>> >>>>>> >>>>>> >>>>>> - Change the DOCKERFILE parameter in releng jjb so that it can >>>>>> accept a comma delimited list of Dockerfile names and paths. Problem >>>>>> with this, of course, is how do I default it to be different for >>>>>> StorPerf >>>>>> vs. Functest, etc? >>>>>> - Change the opnfv-docker.sh to search for the named DOCKERFILE >>>>>> in all subdirectories. This should cover the .aarch64 and vanilla >>>>>> docker >>>>>> file cases. >>>>>> >>>>>> >>>>>> >>>>>> Please +1/-1 or propose other ideas, thanks! >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> *Mark Beierl* >>>>>> >>>>>> SW System Sr Principal Engineer >>>>>> >>>>>> *Dell **EMC* | Office of the CTO >>>>>> >>>>>> mobile +1 613 314 8106 <1-613-314-8106> >>>>>> >>>>>> *[email protected] <[email protected]>* >>>>>> >>>>>> >>>>>> >>>>>> On Jun 24, 2017, at 04:05, Jose Lausuch <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> >>>>>> >>>>>> No need for an additional repo, the logic can be in Releng.. >>>>>> >>>>>> Functest will probably move to different containers some time soon, >>>>>> so that is something we could also leverage. >>>>>> >>>>>> >>>>>> >>>>>> -Jose- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 23 Jun 2017, at 18:39, Julien <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Agree, >>>>>> >>>>>> >>>>>> >>>>>> If StorPerf can list some rules and examples, current scripts can be >>>>>> adapted for multiple docker image building and other project can use this >>>>>> type of changes. It is not deserved to add a new repo just for build a >>>>>> new >>>>>> image. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fatih Degirmenci <[email protected]>于2017年6月21日周三 上午2:26 >>>>>> 写道： >>>>>> >>>>>> Hi Mark, >>>>>> >>>>>> >>>>>> >>>>>> It is perfectly fine to have different build processes and/or number >>>>>> of artifacts for the projects from releng point of view. >>>>>> >>>>>> >>>>>> >>>>>> Once you decide what to do for storperf, we can take a look and adapt >>>>>> docker build job/script to build storperf images, create additional repos >>>>>> on docker hub to push images and activate the builds when things are >>>>>> ready. >>>>>> >>>>>> >>>>>> /Fatih >>>>>> >>>>>> >>>>>> On 20 Jun 2017, at 19:18, Beierl, Mark <[email protected]> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> I'd like to poll the various groups about ideas for how to handle >>>>>> this scenario. I have interns working on breaking down services from >>>>>> StorPerf into different containers. In one case, it will be a simple >>>>>> docker compose that is used to fire up existing containers from the >>>>>> repos, >>>>>> but the other case requires more thought. >>>>>> >>>>>> >>>>>> >>>>>> We are creating a second container (storperf-reporting) that will >>>>>> need to be built and pushed to hub.docker.com. Right now the build >>>>>> process for docker images lives in releng, and it only allows for one >>>>>> image >>>>>> to be built. Should I be requesting a second git repo in this case, or >>>>>> should we look at changing the releng process to allow multiple docker >>>>>> images to be build? >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> *Mark Beierl* >>>>>> >>>>>> SW System Sr Principal Engineer >>>>>> >>>>>> *Dell **EMC* | Office of the CTO >>>>>> >>>>>> mobile +1 613 314 8106 <1-613-314-8106> >>>>>> >>>>>> *[email protected] <[email protected]>* >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> opnfv-tech-discuss mailing list >>>>>> [email protected] >>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>> >>>>>> _______________________________________________ >>>>>> opnfv-tech-discuss mailing list >>>>>> [email protected] >>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>> >>>>>> _______________________________________________ >>>>>> opnfv-tech-discuss mailing list >>>>>> [email protected] >>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> opnfv-tech-discuss mailing list >>>>>> [email protected] >>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>> >>>>> -- >>>>> Yujun Zhang >>>>> >>>>> _______________________________________________ >>>>> opnfv-tech-discuss mailing list >>>>> [email protected] >>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>> >>>>> >>>> _______________________________________________ >>>> opnfv-tech-discuss mailing list >>>> [email protected] >>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>> >>> >>> _______________________________________________ >>> opnfv-tech-discuss mailing list >>> [email protected] >>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>> >>> >>
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
