[Container-tools] OpenShift integration with atomicapp

[Clayton Coleman]

Including aos-devel.

On Fri, Oct 9, 2015 at 8:03 AM, Carl Trieloff <cctrieloff at redhat.com> 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> 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.


That's better.  Or even a label that provides some fundamental info
that is nulecule specific (a unique nulecule id?). Can even just be a
marker label.


>
>> - openshift user token should be passed into the atomicapp pod


Proposed flow:

* oc new-app grabs the image metadata
* if image != nulecule
  * normal flow
* Nulecule requires at minimum edit permission, so for the short term
let's assume the nulecule image needs to use the user's current token
to act as them (in the future we would scope the token down to what
nulecule truly needs, which might be a new default "installer" role or
a list of required permissions and would *only* be for that
namespace).
* Image would define:
  * io.openshift.generate.token.as=env:TOKEN_ENV_VAR
  * (future) io.openshift.generate.token.scope=...
* if ! "--confirm" flag set
  * warn the user that the image is requesting permission to access
the current token
  * exit
* new-app creates a pod (in the future, a job) with
TOKEN_ENV_VAR=$(current_oauth_token)
* new-app would instruct user to watch the job logs (in the future,
would follow the job logs)


>> - 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

We need to get `oc` in a package - we should sync with sdodson and
Troy on the status of that.

>
>
> 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"

Let's hold off on that in the short term just until we can normalize
that with OpenShift templates (even though I agree this is probably
desirable).


>
>
>>
>>
>> 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
>
>