[Container-tools] oc export
Tomas Kral
tkral at redhat.com
Tue Mar 22 17:08:46 UTC 2016
full error message is:
error: Pod "ruby-hello-world-1-" is forbidden: unable to validate
against any security context constraint: [provider anyuid:
.spec.securityContext.seLinuxOptions.level: invalid value 's0:c7,c4',
Details: seLinuxOptions.level on does not match required level. Found
s0:c7,c4, wanted s0:c6,c0 provider anyuid:
.spec.containers[0].securityContext.seLinuxOptions.level: invalid value
's0:c7,c4', Details: seLinuxOptions.level on ruby-hello-world does not
match required level. Found s0:c7,c4, wanted s0:c6,c0 provider
restricted: .spec.securityContext.seLinuxOptions.level: invalid value
's0:c7,c4', Details: seLinuxOptions.level on does not match required
level. Found s0:c7,c4, wanted s0:c6,c0 provider restricted:
.spec.containers[0].securityContext.seLinuxOptions.level: invalid value
's0:c7,c4', Details: seLinuxOptions.level on ruby-hello-world does not
match required level. Found s0:c7,c4, wanted s0:c6,c0]
I'm doing it like this:
export:
$ oc new-project ruby-example
$ oc new-app
centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git
# after build finished
$ oc export all -l app=ruby-hello-world -n ruby-example
--as-template=helloruby > helloruby.yml
on another cluster import like this:
$ oc create -f helloruby.yml
$ oc new-app helloruby
--> Deploying template helloruby for "helloruby"
--> Creating resources with label app=ruby-hello-world ...
BuildConfig "ruby-hello-world" created
Build "ruby-hello-world-1" created
ImageStream "ruby-22-centos7" created
ImageStream "ruby-hello-world" created
DeploymentConfig "ruby-hello-world" created
ReplicationController "ruby-hello-world-1" created
Route "ruby-hello-world" created
Service "ruby-hello-world" created
error: Pod "ruby-hello-world-1-" is forbidden: unable to validate
against any security context constraint:...... <message from above>
On 03/22/2016 05:38 PM, Clayton Coleman wrote:
> Can you describe the error you are seeing?
>
> On Tue, Mar 22, 2016 at 12:25 PM, Tomas Kral <tkral at redhat.com> wrote:
> >
> > On 03/18/2016 08:35 PM, Aaron Weitekamp wrote:
> >> On Tue, Mar 15, 2016 at 9:50 AM, Tomas Kral <tkral at redhat.com
> >> <mailto:tkral at redhat.com>> wrote:
> >>
> >>
> >> On 03/15/2016 02:04 PM, Aaron Weitekamp wrote:
> >> > On Tue, Mar 15, 2016 at 6:20 AM, Tomas Kral <tkral at redhat.com
> >> <mailto:tkral at redhat.com>
> >> > <mailto:tkral at redhat.com <mailto:tkral at redhat.com>>> wrote:
> >> >
> >> >
> >> >
> >> > On 03/14/2016 07:11 PM, Aaron Weitekamp wrote:
> >> > > On Mon, Mar 14, 2016 at 1:10 PM, Tomas Kral
> >> <tkral at redhat.com <mailto:tkral at redhat.com> <mailto:tkral at redhat.com
> >> <mailto:tkral at redhat.com>>
> >> > > <mailto:tkral at redhat.com <mailto:tkral at redhat.com>
> >> <mailto:tkral at redhat.com
> >> <mailto:tkral at redhat.com>>>> wrote:
> >> > >
> >> > > Thank you, that makes sense, but this is also what was
> >> afraid of :(
> >> > >
> >> > > We want to be able to export any arbitrary application
> >> that we know
> >> > > nothing about :(
> >> > > Now we need to figure out which object were generated
> >> by OpenShift
> >> > > internally and which one were created by developer.
> >> > >
> >> > >
> >> > > You're introducing an additional requirement. :) Can you
> >> confirm the
> >> > > initial problem is resolved?
> >> > >
> >> >
> >> > Not really, because I don't know how application was
> deployed.
> >> > My initial assumption that `oc export all` will somehow
> >> magically solve
> >> > this for every application was wrong :(
> >> > If I'm the one who deployed application than yes, I know
> >> what objects to
> >> > export. But if someone else created application it is hard
> >> for me to
> >> > figure out what to export.
> >> >
> >> >
> >> > I think we need to understand the full use case. Maybe there's
> >> > something that can be done to help you achieve what you're
> >> looking for.
> >> > Right now it's hard to understand why the person who did the
> >> original
> >> > deployment
> >> > isn't involved in the export or migration. Can you spell out what
> >> > you're trying to do?
> >> >
> >>
> >> Sure.
> >>
> >> (BTW: I'm CC'ing container-tools because we are starting to touch
> >> subjects that might be interesting for people there)
> >>
> >> We are trying to build tool that will allow users to export
> >> application
> >> from OpenShift as Nulecule application.
> >> Result should be Nulecule application with Kubernetes and OpenShift
> >> artifacts.
> >>
> >> We have following users stories in mind:
> >>
> >> 1.
> >> I create an application in OpenShift.
> >> Now I want to export it so it can be placed in any registry and
> then
> >> redeployed into Kubernetes or OpenShift.
> >>
> >>
> >> It's a good convention to add a label to every object created together,
> >> something like app=<thing>
> >> Then all of those things deployed together can be referenced, such as:
> >>
> >> oc export all -l app=<name> -n <my_namespace> --as-template=<name>
> >
> > And we are back to one of my original issues :-)
> > If I do this as you suggest, with 'all', then when deploying from this
> > template I get some SE Linux error that sadly I know nothing about :(
> > My current solution for this is to export everything except pods.
> >
> >
> >>
> >> If you control the deployment you can pass this label in (web ui, oc
> >> new-app, API).
> >>
> >>
> >>
> >>
> >> 2.
> >> I created a new application from a bunch of 'container
> mirco-sevices'
> >> and components (i.e. a set of nested Nulecules, or templates)
> >> - for example, added management, added a DB etc etc.
> >>
> >> Now I want to export the new composite definition and
> ->Retain<- the
> >> granularity and nesting of my service definitions.
> >>
> >>
> >> I
> >> would recommend unique labels so you can reference things separately.
> >>
> >>
> >>
> >> Result would be set of Nulecule apps (some probably nested) and
> >> corresponding images that can be again placed in registry.
> >>
> >>
> >> 3.
> >> I want to create a new mirco service using OpenShift
> >> I want to export it for OTHER to use.
> >>
> >>
> >>
> >> Right now I'm focusing mainly on number one.
> >>
> >> >
> >> >
> >> >
> >> >
> >> > > If you're comfortable with exporting everything in a
> project
> >> then
> >> > > replace "all" with the set of resources Clayton listed.
> >> >
> >> > You and Clayton suggested doing `oc export dc,svc,route,is`
> >> but what if
> >> > application also includes ReplicationControllers that were
> >> created
> >> > directly without DeploymentConfig?
> >> > For example I have RC that was created "directly by user" and
> >> other RC
> >> > that was created by DC. Now I need to export only first
> RC and
> >> instead
> >> > of second one I should export DC.
> >> >
> >> > It looks like, that for our use case, we need to export 'all'
> >> and than
> >> > do some filtering.
> >> > This is was what my followup question was about.
> >> >
> >> > Is there a way how to figure out what objects were created by
> >> user and
> >> > what objects were generated by OpenShift?
> >> > Can annotations that I have mentioned be used for this?
> >> >
> >> > > It is
> >> > > dangerously presumptive that there's only one
> >> "application" in a
> >> > > project. You may export unexpected objects depending on
> what
> >> the user
> >> > > has deployed in the project.
> >> >
> >> > This is deliberate simplification to make things little
> easier
> >> for us.
> >> > We are exporting whole project, because right now I don't
> have
> >> any idea
> >> > how we are going to decide what is "one application" or how
> >> user of this
> >> > exporter should specify this.
> >> >
> >> > >
> >> > >
> >> > > I can see that ReplicationController that is
> generated by
> >> > > DeploymentConfig has annotation
> >> 'openshift.io/deployment-config.name
> >> <http://openshift.io/deployment-config.name>
> >> > <http://openshift.io/deployment-config.name>
> >> > > <http://openshift.io/deployment-config.name>:
> >> > > ...' and same apply for its Pods.
> >> > >
> >> > > For Pod that was created by ReplicationController (that
> >> is not from
> >> > > DeploymentConfig) I see annotation
> >> 'kubernetes.io/created-by <http://kubernetes.io/created-by>
> >> <http://kubernetes.io/created-by>
> >> > > <http://kubernetes.io/created-by>: ...'
> >> > >
> >> > > Can we rely on those annotations to decide what to
> >> export and what to
> >> > > leave behind? Is this documented somewhere?
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On 03/14/2016 04:48 PM, Clayton Coleman wrote:
> >> > > > Export is a lower level tool that does not *exactly*
> >> export an entire
> >> > > > application, but rather tries to give you the
> tools to
> >> build it.
> >> > > >
> >> > > > I would suggest instead of running "oc export all",
> >> you try "oc export
> >> > > > dc,svc,route,is". "all" includes pods, replication
> >> controllers,
> >> > > > build configs, and builds, some of which you do not
> >> need. We expect
> >> > > > at some point in the future to have a higher level
> >> "export-app"
> >> > > > command, but when you export you need to determine
> >> what you want to
> >> > > > copy over and what you want to leave behind.
> >> > > >
> >> > > > On Mon, Mar 14, 2016 at 11:13 AM, Tomas Kral
> >> <tkral at redhat.com <mailto:tkral at redhat.com>
> <mailto:tkral at redhat.com
> >> <mailto:tkral at redhat.com>>
> >> > > <mailto:tkral at redhat.com <mailto:tkral at redhat.com>
> >> <mailto:tkral at redhat.com <mailto:tkral at redhat.com>>>> wrote:
> >> > > >> Hi all,
> >> > > >> I'm working on project where we are basically
> using `oc
> >> > export` for
> >> > > >> exporting project and importing it to another
> OpenShift
> >> > instance.
> >> > > >>
> >> > > >> But it is not working as I would expect.
> >> > > >>
> >> > > >> My understanding of export feature is that it can
> >> be used
> >> > to move
> >> > > >> objects between clusters or projects and I can
> use `oc
> >> > export all` to
> >> > > >> move/copy whole project.
> >> > > >>
> >> > > >> I've deployed MLB Parks sample application
> >> > > >> (https://github.com/gshipley/openshift3mlbparks)
> >> > > >>
> >> > > >> Then I'm trying to move it to another project on
> same
> >> cluster
> >> > > using command:
> >> > > >>
> >> > > >> oc -n mlbparks export all | oc -n import create -f -
> >> > > >>
> >> > > >>
> >> > > >> But I get following errors:
> >> > > >>
> >> > > >> Error from server: replicationControllers
> "mongodb-1"
> >> > already exists
> >> > > >> Error from server: Pod "mlbparks-1-build" is
> forbidden:
> >> > unable to
> >> > > >> validate against any security context constraint:
> >> ......
> >> > > >>
> >> > > >> Rest of the error and all steps that I'm doing are
> >> here:
> >> > > >> http://paste.fedoraproject.org/339618/96469114/
> >> > > >>
> >> > > >>
> >> > > >> I'm running Origin v1.1.1
> >> > > >>
> >> > > >>
> >> > > >> Is there something that is fundamentally wrong
> with my
> >> > > understanding of
> >> > > >> `oc export`?
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Tomas
> >> > > >>
> >> > > >> _______________________________________________
> >> > > >> dev mailing list
> >> > > >> dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>
> >> > <mailto:dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>>
> >> > > <mailto:dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>
> >> > <mailto:dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>>>
> >> > > >>
> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> > >
> >> > > _______________________________________________
> >> > > dev mailing list
> >> > > dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>
> >> > <mailto:dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>>
> >> > <mailto:dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>
> >> > <mailto:dev at lists.openshift.redhat.com
> >> <mailto:dev at lists.openshift.redhat.com>>>
> >> > >
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
More information about the Container-tools
mailing list