<div dir="ltr"><div class="gmail_default" style="font-size:small">Here's a quick picture of the proposal. </div><div class="gmail_default" style="font-size:small"><a href="https://docs.google.com/drawings/d/13mfTkxv_M3jM6WMsgpJtoKkX4nuVuTPcPSfsebN3qKA/edit?usp=sharing">https://docs.google.com/drawings/d/13mfTkxv_M3jM6WMsgpJtoKkX4nuVuTPcPSfsebN3qKA/edit?usp=sharing</a> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Oct 12, 2015 at 8:58 PM, Clayton Coleman <<a href="mailto:ccoleman@redhat.com" target="_blank">ccoleman@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Including aos-devel. On Fri, Oct 9, 2015 at 8:03 AM, Carl Trieloff <<a href="mailto:cctrieloff@redhat.com">cctrieloff@redhat.com</a>> 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 <<a href="mailto:aweiteka@redhat.com">aweiteka@redhat.com</a>> 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: * <a href="http://io.openshift.generate.token.as" rel="noreferrer" target="_blank">io.openshift.generate.token.as</a>=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). <div class="HOEnZb"><div class="h5"> > > >> >> >> 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 > <a href="mailto:Container-tools@redhat.com">Container-tools@redhat.com</a> > <a href="https://www.redhat.com/mailman/listinfo/container-tools" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/container-tools</a> > > </div></div></blockquote></div> </div>