[Container-tools] [aos-devel] OpenShift integration with atomicapp

[Jordan Liggitt]

On Mon, Oct 12, 2015 at 8:58 PM, Clayton Coleman <ccoleman at redhat.com>
wrote:

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

We shouldn't be automating things that expose a user's API credentials in a
project in a way that is visible to other users. Doing so using pod envvars
exposes them even further, so that anyone who even had view permission on
the project would have access to the user's credentials.



>
> >> - 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151015/f16088d8/attachment.htm>