[Container-tools] OpenShift integration with atomicapp

[Aaron Weitekamp]

Here's a quick picture of the proposal.

https://docs.google.com/drawings/d/13mfTkxv_M3jM6WMsgpJtoKkX4nuVuTPcPSfsebN3qKA/edit?usp=sharing

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)
>
>
> >> - 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/20151014/7dc1f35e/attachment.htm>