[Container-tools] OpenShift integration with atomicapp

[Carl Trieloff]

one last comment is that this solves the use case that of we don't want
to have to introduce two tools to a new Openshift user of oc  to pull
from registry. however it still allows them to run AtomicApp if they to
get to the full set of AtomicApp verbs and namespace/param options

Carl.


On 10/09/2015 08:03 AM, Carl Trieloff wrote:
>
> yip looks good
>
> On 10/08/2015 09:37 PM, Aaron Weitekamp wrote:
>> On Thu, Oct 8, 2015 at 5:08 PM, Aaron Weitekamp <aweiteka at redhat.com
>> <mailto:aweiteka at redhat.com>> wrote:
>>
>>     Speaking with Clayton we believe we have a path to running an
>>     atomicapp using native OpenShift 'oc' CLI.
>>
>>     *Proposal:*
>>
>>     oc new-app <atomicapp-image> [-p foo=bar,bee=baz]
>>
>>     This command will kick off running the image in a pod. Inside
>>     this pod oc commands will be executed as the user. Remote or
>>     composite atomicapps will be chained in the same way via oc
>>     new-app <remote-image>.
>>
>>     For MVP we will not support answerfile or interactive install
>>     since oc does not have a mechanism for that today.
>>
>>     All other application lifecycle commands will be handled by
>>     native oc commands as they are today, outside of atomicapp.
>>
>>     *Required changes (for discussion):*
>>     - identify an io.openshift label for atomicapp image that
>>     identifies as an atomicapp
>>
>
>  we could also call it something like io.nulecule.executable so that
> it is not openshift specific but a generic so any tool can read the
> label.. which openshift looks for.
>
>>     - openshift user token should be passed into the atomicapp pod
>>     - atomicapp openshift provider should not call docker but use the
>>     oc client
>>     - params need to be passed into atomicapp pod and need to be
>>     parsed by atomicapp
>>     - oc client either needs to be built into atomicapp or a sidecar
>>     container needs to be spun up in the same pod. TBD
>>
>>
>> ​One more item: since the oc command won't be aware of the params
>> until the remote pod is run I think we need to bake these into the
>> image metadata and extend openshift to display these. Otherwise the
>> end-user will not know what the params are.​ Something like this in
>> the Dockerfile:
>>
>> LABEL io.openshift.my-app.parameter.FOO.default="bar" \
>>             io.openshift.my-app.parameter.FOO.description="Some foo
>> for your bar"
>>
>>  
>>
>>
>>     There are probably many other details I'm missing. It basically
>>     means some patches to openshift, refactor openshift provider and
>>     support all the edge cases to handle params, etc.
>>
>>
>>
>>
>> _______________________________________________
>> Container-tools mailing list
>> Container-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/container-tools
>
>
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151009/028afa03/attachment.htm>