From marc.boorshtein at tremolosecurity.com Wed Jun 1 16:05:43 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 1 Jun 2016 11:05:43 -0500 Subject: [Openshift Commons Image Builders SIG] source2image and compiling java...where's the right place to do it? Message-ID: Fellow builders, We're building a source2image builder for our Java application and we're struggling with the question of where to actually build the system. The output of a maven build process is a war file that goes into a hardened version of Tomcat. We see three options: 1. Input is a war file created as the output of an external build - simple for us but seems to defeat the purpose of s2i 2. Assume that maven and javac are wherever s2i is running and have the assemble script pull the maven project, build it and deploy the war file into the image - This seems the most obvious to me since it lets us rely on existing build processes. 3. Pull in maven and the source code into the image, then have the image build the project, deploy the wars and then remove maven and the source code - This seems like it would be the most consistent way to do a build since it wouldn't matter which system s2i runs on but it requires the most amount of work on our end. Any thoughts/advise on the best or recommended approach? Is there one that we're missing? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 Twitter - @mlbiam / @tremolosecurity From jmorales at redhat.com Thu Jun 2 08:57:56 2016 From: jmorales at redhat.com (Jorge Morales Pou) Date: Thu, 2 Jun 2016 10:57:56 +0200 Subject: [Openshift Commons Image Builders SIG] source2image and compiling java...where's the right place to do it? In-Reply-To: References: Message-ID: Hi Marc, Our current s2i builders expect the source code to be provided, and the build to happen in OpenShift, but this is just an actual limitation of our builders rather than the platform. A custom s2i image can be crafted so that instead of expecting the source code to build the application, it just get's the generated artifact and layers that on top of a runtime image (Tomcat in your example). For this, we've been working, and keep doing, into making this scenario easier, by: - Making a source repository optional (OSE 3.3) - Providing binaries to the build process (3.2: https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source ) - Providing content from another image (3.2: https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source ) - Splitting the build process into builder + runtime images (3.3) - Provide additional information in webhooks (3.3) With these tools in place, it would be trivial to make an s2i that fetches a binary artifact from an artifact repository manager (nexus, artifactory) on the coordinates provided via webhook or start-build options, and just layer the artifact into a runtime image. This will be an OOTB scenario for 3.3, until then, some manual crafting need to be done, but still possible, by a custom assemble script as an example. https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/ If your using one of our s2i, option 2 seems the way to go (or even if you're crafting your own, you can follow similar approach, following our wildfly s2i https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0). As I mentioned before, we will be splitting builder and runtime image, so you will no longer need to have javac + maven on the s2i image, but rather you'll have a maven builder and a tomcat runtime, and the generated artifact will be copied from the former to the later automagically in the s2i process. You can see details here: https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg. This is a Work in Progress, that will be in OSE 3.3. Also, this can be currently achieved by combining 2 builds and chaining them. The image built in the first build (which would be just java + maven) will be used as source for the second build to get the artifact into a plain Tomcat. The 3rd option seems like a big boilerplate to craft in an image, so I would rather recommend either option 2 or 1. Hope this helps, Jorge Morales OpenShift by Red Hat EMEA Field Product Manager Product Marketing Manager On Wed, Jun 1, 2016 at 6:05 PM, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > Fellow builders, > > We're building a source2image builder for our Java application and > we're struggling with the question of where to actually build the > system. The output of a maven build process is a war file that goes > into a hardened version of Tomcat. We see three options: > > 1. Input is a war file created as the output of an external build - > simple for us but seems to defeat the purpose of s2i > > 2. Assume that maven and javac are wherever s2i is running and have > the assemble script pull the maven project, build it and deploy the > war file into the image - This seems the most obvious to me since it > lets us rely on existing build processes. > > 3. Pull in maven and the source code into the image, then have the > image build the project, deploy the wars and then remove maven and the > source code - This seems like it would be the most consistent way to > do a build since it wouldn't matter which system s2i runs on but it > requires the most amount of work on our end. > > Any thoughts/advise on the best or recommended approach? Is there one > that we're missing? > > Thanks > > > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > Twitter - @mlbiam / @tremolosecurity > > _______________________________________________ > Openshift-commons-sig-image-builders mailing list > Openshift-commons-sig-image-builders at redhat.com > > https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.boorshtein at tremolosecurity.com Thu Jun 2 10:48:05 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Thu, 2 Jun 2016 05:48:05 -0500 Subject: [Openshift Commons Image Builders SIG] source2image and compiling java...where's the right place to do it? In-Reply-To: References: Message-ID: Thanks Jorge. I'd think it'd be good to have both option 1 (source) and option 2 (binaries) since option 1 is good for just testing locally but if you have a full ci/cd pipeline it would be better for the ci/cd pipeline to do the build to get the benefits of managing of having consistent artifacts? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 Twitter - @mlbiam / @tremolosecurity On Thu, Jun 2, 2016 at 3:57 AM, Jorge Morales Pou wrote: > Hi Marc, > Our current s2i builders expect the source code to be provided, and the > build to happen in OpenShift, but this is just an actual limitation of our > builders rather than the platform. A custom s2i image can be crafted so that > instead of expecting the source code to build the application, it just get's > the generated artifact and layers that on top of a runtime image (Tomcat in > your example). > For this, we've been working, and keep doing, into making this scenario > easier, by: > - Making a source repository optional (OSE 3.3) > - Providing binaries to the build process (3.2: > https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source) > - Providing content from another image (3.2: > https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source) > - Splitting the build process into builder + runtime images (3.3) > - Provide additional information in webhooks (3.3) > With these tools in place, it would be trivial to make an s2i that fetches a > binary artifact from an artifact repository manager (nexus, artifactory) on > the coordinates provided via webhook or start-build options, and just layer > the artifact into a runtime image. This will be an OOTB scenario for 3.3, > until then, some manual crafting need to be done, but still possible, by a > custom assemble script as an example. > https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts > http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/ > > If your using one of our s2i, option 2 seems the way to go (or even if > you're crafting your own, you can follow similar approach, following our > wildfly s2i https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0). > As I mentioned before, we will be splitting builder and runtime image, so > you will no longer need to have javac + maven on the s2i image, but rather > you'll have a maven builder and a tomcat runtime, and the generated artifact > will be copied from the former to the later automagically in the s2i > process. You can see details here: > https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg. > This is a Work in Progress, that will be in OSE 3.3. Also, this can be > currently achieved by combining 2 builds and chaining them. The image built > in the first build (which would be just java + maven) will be used as source > for the second build to get the artifact into a plain Tomcat. > > The 3rd option seems like a big boilerplate to craft in an image, so I would > rather recommend either option 2 or 1. > > Hope this helps, > > Jorge Morales > OpenShift by Red Hat > EMEA Field Product Manager > Product Marketing Manager > > On Wed, Jun 1, 2016 at 6:05 PM, Marc Boorshtein > wrote: >> >> Fellow builders, >> >> We're building a source2image builder for our Java application and >> we're struggling with the question of where to actually build the >> system. The output of a maven build process is a war file that goes >> into a hardened version of Tomcat. We see three options: >> >> 1. Input is a war file created as the output of an external build - >> simple for us but seems to defeat the purpose of s2i >> >> 2. Assume that maven and javac are wherever s2i is running and have >> the assemble script pull the maven project, build it and deploy the >> war file into the image - This seems the most obvious to me since it >> lets us rely on existing build processes. >> >> 3. Pull in maven and the source code into the image, then have the >> image build the project, deploy the wars and then remove maven and the >> source code - This seems like it would be the most consistent way to >> do a build since it wouldn't matter which system s2i runs on but it >> requires the most amount of work on our end. >> >> Any thoughts/advise on the best or recommended approach? Is there one >> that we're missing? >> >> Thanks >> >> >> Marc Boorshtein >> CTO Tremolo Security >> marc.boorshtein at tremolosecurity.com >> (703) 828-4902 >> Twitter - @mlbiam / @tremolosecurity >> >> _______________________________________________ >> Openshift-commons-sig-image-builders mailing list >> Openshift-commons-sig-image-builders at redhat.com >> >> https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders > > From jmorales at redhat.com Thu Jun 2 11:10:57 2016 From: jmorales at redhat.com (Jorge Morales Pou) Date: Thu, 2 Jun 2016 13:10:57 +0200 Subject: [Openshift Commons Image Builders SIG] source2image and compiling java...where's the right place to do it? In-Reply-To: References: Message-ID: Sure, and once we split the builder and the runtime you'll be able to easily achieve. The question here, I guess, is whether you want to have javac + maven in your runtime, since those are not required to running the app. Once we do the split, you'll be able to use a builder image for getting from source code to artifact, and then the runtime would be used for both use cases, streaming from the builder or providing the artifact from a remote location. In your usa case, and with your tools at hand, I would recommend creating a minimal asemble script that fits both purposes, and then reevaluate once there's more options at hand. In any case, how you build your images, should always be the same, as the image, once created is the thing that promotes between environments, and there's no need to rebuild the image again with a different strategy. In any case, we're still learning how people uses our platform, and how they will to use it, so any comment/discussion will be very much appreciated. Our goal is to make a flexible platform, so if it is not already, working into it. Cheers, Jorge Morales OpenShift by Red Hat EMEA Field Product Manager Product Marketing Manager On Thu, Jun 2, 2016 at 12:48 PM, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > Thanks Jorge. I'd think it'd be good to have both option 1 (source) > and option 2 (binaries) since option 1 is good for just testing > locally but if you have a full ci/cd pipeline it would be better for > the ci/cd pipeline to do the build to get the benefits of managing of > having consistent artifacts? > > Thanks > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > Twitter - @mlbiam / @tremolosecurity > > > On Thu, Jun 2, 2016 at 3:57 AM, Jorge Morales Pou > wrote: > > Hi Marc, > > Our current s2i builders expect the source code to be provided, and the > > build to happen in OpenShift, but this is just an actual limitation of > our > > builders rather than the platform. A custom s2i image can be crafted so > that > > instead of expecting the source code to build the application, it just > get's > > the generated artifact and layers that on top of a runtime image (Tomcat > in > > your example). > > For this, we've been working, and keep doing, into making this scenario > > easier, by: > > - Making a source repository optional (OSE 3.3) > > - Providing binaries to the build process (3.2: > > > https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source > ) > > - Providing content from another image (3.2: > > > https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source > ) > > - Splitting the build process into builder + runtime images (3.3) > > - Provide additional information in webhooks (3.3) > > With these tools in place, it would be trivial to make an s2i that > fetches a > > binary artifact from an artifact repository manager (nexus, artifactory) > on > > the coordinates provided via webhook or start-build options, and just > layer > > the artifact into a runtime image. This will be an OOTB scenario for 3.3, > > until then, some manual crafting need to be done, but still possible, by > a > > custom assemble script as an example. > > > https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts > > > http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/ > > > > If your using one of our s2i, option 2 seems the way to go (or even if > > you're crafting your own, you can follow similar approach, following our > > wildfly s2i > https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0). > > As I mentioned before, we will be splitting builder and runtime image, so > > you will no longer need to have javac + maven on the s2i image, but > rather > > you'll have a maven builder and a tomcat runtime, and the generated > artifact > > will be copied from the former to the later automagically in the s2i > > process. You can see details here: > > > https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg > . > > This is a Work in Progress, that will be in OSE 3.3. Also, this can be > > currently achieved by combining 2 builds and chaining them. The image > built > > in the first build (which would be just java + maven) will be used as > source > > for the second build to get the artifact into a plain Tomcat. > > > > The 3rd option seems like a big boilerplate to craft in an image, so I > would > > rather recommend either option 2 or 1. > > > > Hope this helps, > > > > Jorge Morales > > OpenShift by Red Hat > > EMEA Field Product Manager > > Product Marketing Manager > > > > On Wed, Jun 1, 2016 at 6:05 PM, Marc Boorshtein > > wrote: > >> > >> Fellow builders, > >> > >> We're building a source2image builder for our Java application and > >> we're struggling with the question of where to actually build the > >> system. The output of a maven build process is a war file that goes > >> into a hardened version of Tomcat. We see three options: > >> > >> 1. Input is a war file created as the output of an external build - > >> simple for us but seems to defeat the purpose of s2i > >> > >> 2. Assume that maven and javac are wherever s2i is running and have > >> the assemble script pull the maven project, build it and deploy the > >> war file into the image - This seems the most obvious to me since it > >> lets us rely on existing build processes. > >> > >> 3. Pull in maven and the source code into the image, then have the > >> image build the project, deploy the wars and then remove maven and the > >> source code - This seems like it would be the most consistent way to > >> do a build since it wouldn't matter which system s2i runs on but it > >> requires the most amount of work on our end. > >> > >> Any thoughts/advise on the best or recommended approach? Is there one > >> that we're missing? > >> > >> Thanks > >> > >> > >> Marc Boorshtein > >> CTO Tremolo Security > >> marc.boorshtein at tremolosecurity.com > >> (703) 828-4902 > >> Twitter - @mlbiam / @tremolosecurity > >> > >> _______________________________________________ > >> Openshift-commons-sig-image-builders mailing list > >> Openshift-commons-sig-image-builders at redhat.com > >> > >> > https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbsingh at redhat.com Wed Jun 8 14:53:47 2016 From: kbsingh at redhat.com (Karanbir Singh) Date: Wed, 8 Jun 2016 15:53:47 +0100 Subject: [Openshift Commons Image Builders SIG] SIG Meeting Reminder: OpenShift Commons Image Builder SIG Wednesday June 1st 8:00 am Pacific In-Reply-To: References: Message-ID: <629b97d0-d9dd-9c36-a7f2-8492e3c14828@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Folks, There seems to have been a misunderstanding here - we were not aware that the content from the preso was going to be made public. The talk that Dharmit and Zeeshan did was very much targeting an internal audience as to where we are going. We are, ofcourse, happy to welcome the openshift commons sig image builders group to join the CentOS Container Pipeline effort and promote it as such, but were not quite there yet ( including urls are still being mapped out and the process is largely not user ready ). The public videos and the blog posts caught us by surprise here, including Dharmit and Zeeshan. And I was wondering if there was anything to be done there ? One option is that we can push something out from the CentOS side, welcoming the openshift upstream into the pipeline effort as their preferred build process ? And use that as a way to soft announce the entire initiative publicly. Who on the openshift side woud/should I be co-ordinating that with. Is there any other group who'd like to be in that announcement from our side ? regards On 31/05/16 23:51, Diane Mueller-Klingspor wrote: > The CentOS Community has developed a workflow for building images. > Dharmit Shah and Mohammed Zeeshan will be giving an overview/demo > on how the CentOS Community Container Pipeline works and lead a > discussion & Q/A session for those interested in learning more. > https://github.com/kbsingh/cccp-index > > > The meeting tomorrow will start at 8:00 am Pacific with a > presentation from two of the Centos team on their Container > Pipeline. > > Here are the meeting details: > > To join the Meeting: https://bluejeans.com/350429644 > > To join via Browser: https://bluejeans.com/350429644/browser > > To join with Lync: https://bluejeans.com/350429644/lync > > To join via Room System: Video Conferencing System: bjn.vc > -or-199.48.152.152 Meeting ID : 350429644 > > To join via phone : 1) Dial: +1 800 451 8679 +1 212 729 5016 (see > all numbers - > https://www.intercallonline.com/listNumbersByCode.action?confCode=8933 049334) > > 2) Enter Conference ID : 8933049334 > > > Kind Regards, > > Diane Mueller Director, Community Development Red Hat OpenShift > @openshiftcommons > > We have more in Common than you know, learn more at > http://commons.openshift.org > > > > _______________________________________________ > Openshift-commons-sig-image-builders mailing list > Openshift-commons-sig-image-builders at redhat.com > https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-bu ilders > > - -- Karanbir Singh, Project Lead, The CentOS Project, London, UK Red Hat Ext. 8274455 | DID: 0044 207 009 4455 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXWDF7AAoJEI3Oi2Mx7xbtiF8IAIvcu6ugk1T1M7O8finPlz+4 uQ6X8G72vcxlcUuCebnsTJit7n1hl1KjVEFyzzXdX0LruGpM566z8VuLxwLGRYtq GK4mFKVqZi62GsHAYgeqNBYHVRR8LtomJizBr4kd5Di1HZaf7Z3aPlPXOrtw39WJ ekCWP0v1FtO/cF3LNe1z5YSdRJbJZlCdoCZQ1vQsnoiMxMYK3cxXohHs+05n7IRw aLR+bhC6JtXUGOHKEMSWjZo3IMce1x0FnBUM35+cPLpaVmfpFJ67rASWyzFlb4M8 acOjFeQqWXSal62vATo4owx7o80EIC4nf9UTL0YxTyWDMa/iy8AXMZu7+2gXfUA= =s0F5 -----END PGP SIGNATURE----- From dmueller at redhat.com Mon Jun 13 17:02:58 2016 From: dmueller at redhat.com (Diane Mueller-Klingspor) Date: Mon, 13 Jun 2016 10:02:58 -0700 Subject: [Openshift Commons Image Builders SIG] June 15th Image Builder SIG speaker/topic is: Adam Miller & Fedora's Container Build Service Message-ID: What: Bi-monthly Image Builder SIG Meeting Date/Time: June 15th at 9:00 am Pacific Topic: Fedora Container Builder Service & Fedora Cloud explained Adam Miller , (aka @Maxamillion) Senior Software Engineer at Red Hat is the Fedora Release Manager and leading the charge on the Fedora Container Build Service. He is going to give us an walk-thru and overview of the Fedora Container Build Service and a intro to the Fedora Cloud initiative. Special Guest appearance from Matthew Millar, Fedora Community Lead. To join the Meeting: https://bluejeans.com/344538224 To join via Browser: https://bluejeans.com/344538224/browser To join with Lync: https://bluejeans.com/344538224/lync To join via Room System: Video Conferencing System: bjn.vc -or-199.48.152.152 Meeting ID : 344538224 To join via phone : 1) Dial: +1 800 451 8679 +1 212 729 5016 (see all numbers - https://www.intercallonline.com/listNumbersByCode.action?confCode=8933049334 ) 2) Enter Conference ID : 8933049334 Kind Regards, Diane Mueller Director, Community Development Red Hat OpenShift @openshiftcommons We have more in Common than you know, learn more at http://commons.openshift.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmueller at redhat.com Wed Jun 15 15:07:27 2016 From: dmueller at redhat.com (Diane Mueller-Klingspor) Date: Wed, 15 Jun 2016 08:07:27 -0700 Subject: [Openshift Commons Image Builders SIG] SIG Meeting Reminder: OpenShift Commons Image Builder SIG Wednesday June 1st 8:00 am Pacific In-Reply-To: <629b97d0-d9dd-9c36-a7f2-8492e3c14828@redhat.com> References: <629b97d0-d9dd-9c36-a7f2-8492e3c14828@redhat.com> Message-ID: KB, All the SIGs and Briefings presentations are recorded and public; they are posted on our youtube channel. Do you need us to de-list the Centos Container Pipeline presentation until you are ready for it's promotion? That can be easily done today and I will do so now. As with today's Fedora Image Builder Service topic, all the conversations around these topics are basically forward-looking and works-in-progress. I believe the community and SIG members all understand this and the idea is to get feedback and start building awareness of the initiatives. Here's the link to today's SIG meeting starting at 9:00 am Pacific on June 15th if you (or anyone else would like to join in for a preview of what the Fedora community is working on). https://bluejeans.com/344538224 Kind Regards, Diane Mueller Director, Community Development Red Hat OpenShift @openshiftcommons We have more in Common than you know, learn more at http://commons.openshift.org On Wed, Jun 8, 2016 at 7:53 AM, Karanbir Singh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Folks, > > There seems to have been a misunderstanding here - we were not aware > that the content from the preso was going to be made public. The talk > that Dharmit and Zeeshan did was very much targeting an internal > audience as to where we are going. > > We are, ofcourse, happy to welcome the openshift commons sig image > builders group to join the CentOS Container Pipeline effort and > promote it as such, but were not quite there yet ( including urls are > still being mapped out and the process is largely not user ready ). > > The public videos and the blog posts caught us by surprise here, > including Dharmit and Zeeshan. And I was wondering if there was > anything to be done there ? > > One option is that we can push something out from the CentOS side, > welcoming the openshift upstream into the pipeline effort as their > preferred build process ? And use that as a way to soft announce the > entire initiative publicly. > > Who on the openshift side woud/should I be co-ordinating that with. Is > there any other group who'd like to be in that announcement from our > side ? > > regards > > On 31/05/16 23:51, Diane Mueller-Klingspor wrote: > > The CentOS Community has developed a workflow for building images. > > Dharmit Shah and Mohammed Zeeshan will be giving an overview/demo > > on how the CentOS Community Container Pipeline works and lead a > > discussion & Q/A session for those interested in learning more. > > https://github.com/kbsingh/cccp-index > > > > > > The meeting tomorrow will start at 8:00 am Pacific with a > > presentation from two of the Centos team on their Container > > Pipeline. > > > > Here are the meeting details: > > > > To join the Meeting: https://bluejeans.com/350429644 > > > > To join via Browser: https://bluejeans.com/350429644/browser > > > > To join with Lync: https://bluejeans.com/350429644/lync > > > > To join via Room System: Video Conferencing System: bjn.vc > > -or-199.48.152.152 Meeting ID : 350429644 > > > > To join via phone : 1) Dial: +1 800 451 8679 +1 212 729 5016 (see > > all numbers - > > https://www.intercallonline.com/listNumbersByCode.action?confCode=8933 > 049334) > > > > > 2) Enter Conference ID : 8933049334 > > > > > > Kind Regards, > > > > Diane Mueller Director, Community Development Red Hat OpenShift > > @openshiftcommons > > > > We have more in Common than you know, learn more at > > http://commons.openshift.org > > > > > > > > _______________________________________________ > > Openshift-commons-sig-image-builders mailing list > > Openshift-commons-sig-image-builders at redhat.com > > https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-bu > ilders > > > > > - -- > Karanbir Singh, Project Lead, The CentOS Project, London, UK > Red Hat Ext. 8274455 | DID: 0044 207 009 4455 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJXWDF7AAoJEI3Oi2Mx7xbtiF8IAIvcu6ugk1T1M7O8finPlz+4 > uQ6X8G72vcxlcUuCebnsTJit7n1hl1KjVEFyzzXdX0LruGpM566z8VuLxwLGRYtq > GK4mFKVqZi62GsHAYgeqNBYHVRR8LtomJizBr4kd5Di1HZaf7Z3aPlPXOrtw39WJ > ekCWP0v1FtO/cF3LNe1z5YSdRJbJZlCdoCZQ1vQsnoiMxMYK3cxXohHs+05n7IRw > aLR+bhC6JtXUGOHKEMSWjZo3IMce1x0FnBUM35+cPLpaVmfpFJ67rASWyzFlb4M8 > acOjFeQqWXSal62vATo4owx7o80EIC4nf9UTL0YxTyWDMa/iy8AXMZu7+2gXfUA= > =s0F5 > -----END PGP SIGNATURE----- > > _______________________________________________ > Openshift-commons-sig-image-builders mailing list > Openshift-commons-sig-image-builders at redhat.com > > https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders > -- Kind Regards, Diane Mueller Director, Community Development Red Hat OpenShift @openshiftcommons We have more in Common than you know, learn more at http://commons.openshift.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmueller at redhat.com Wed Jun 15 15:21:52 2016 From: dmueller at redhat.com (Diane Mueller-Klingspor) Date: Wed, 15 Jun 2016 08:21:52 -0700 Subject: [Openshift Commons Image Builders SIG] Reminder: Next SIG Meeting is today! Fedora Build Service talk starting at 9:00 am Pacific today Message-ID: Adam Miller , (aka @Maxamillion) Senior Software Engineer at Red Hat is the Fedora Release Manager and leading the charge on the Fedora Container Build Service. He is going to give us an walk-thru and overview of the Fedora Container Build Service and a intro to the Fedora Cloud initiative. Special Guest appearance from Matthew Millar, Fedora Community Lead. Starts at 9:00 am Pacific on June 15th Here are the meeting details: To join the Meeting: https://bluejeans.com/344538224 To join via Browser: https://bluejeans.com/344538224/browser To join with Lync: https://bluejeans.com/344538224/lync To join via Room System: Video Conferencing System: bjn.vc -or-199.48.152.152 Meeting ID : 344538224 To join via phone : 1) Dial: +1 800 451 8679 +1 212 729 5016 (see all numbers - https://www.intercallonline.com/listNumbersByCode.action?confCode=8933049334 ) 2) Enter Conference ID : 8933049334 -- Kind Regards, Diane Mueller Director, Community Development Red Hat OpenShift @openshiftcommons We have more in Common than you know, learn more at http://commons.openshift.org -------------- next part -------------- An HTML attachment was scrubbed... URL: