Re: SCC privileged not applying

2017-12-19 Thread Weiwei Jiang
Further more discussion here.
https://github.com/kubernetes/kubernetes/issues/57378

On Tue, Dec 19, 2017 at 9:54 PM Jordan Liggitt  wrote:

> > On Dec 19, 2017, at 1:49 AM, Weiwei Jiang  wrote:
> >
> > But the scc is trying to verify the creater account(you can see this
> with audit enabled), and should be daemonset-controller or something like
> this but not the given serviceaccount).
>
> That's not accurate. You can give the SCC permissions to either the
> creating user (in the case of a daemonset, this is the daemonset
> controller) and/or to the service account of this pod.
>
> You should avoid giving SCC permissions to the pod creating
> controllers, since that enables any user that can create a daemonset
> to make use of those permissions via the controller.
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: OpenShift Jenkins Pipeline (DSL) Plugin : erroneous 'incorrect namespace' error from create()?

2017-12-19 Thread Alan Christie
Thanks, issue created…

https://github.com/openshift/jenkins-client-plugin/issues/96 


For now the work-around gets me out of the hole. Cheers.

Alan.

> On 19 Dec 2017, at 14:26, Justin Pierce  wrote:
> 
> The plugin tries to simplify namespace handling for the majority of cases. In 
> your particular case, that attempt to help is detrimental. 
> 
> An issue would probably be appreciated. I've copied Gabe, the active 
> maintainer. 
> 
> On Tue, Dec 19, 2017 at 9:20 AM, Alan Christie 
> > 
> wrote:
> Thanks Justin,
> 
> Is it of interest that the plugin’s create() behaves differently to the 
> command-line? It just doesn't _feel_ right. I could create an issue in the 
> client plugin GitHub project if the consensus is that the behaviour is wrong. 
> After all, why does create() care? Its command-line-cousin doesn’t.
> 
> At the moment my work-around (inspecting the namespace) and iterating through 
> the objects feels more pleasant than using raw.
> 
> Alan.
> 
> 
>> On 19 Dec 2017, at 14:09, Justin Pierce > > wrote:
>> 
>> Alan - This might be a use case for the openshift.raw API [1]. It will 
>> simply pass through any arguments you give it. 
>> 
>> Best Regards,
>> Justin
>> [1] https://github.com/openshift/jenkins-client-plugin#i-need-more 
>> 
>> 
>> On Tue, Dec 19, 2017 at 6:57 AM, Alan Christie 
>> > 
>> wrote:
>> I appear to be able to work-around the problem by iterating through the 
>> objects created by the call to process() and conditionally setting the 
>> namespace, i.e. by doing this…
>> 
>>  def objs = openshift.process('—filename=’)
>>  for (obj in objs) {
>>  if (obj.metadata.namespace == “X") {
>>  openshift.create(obj, "—namespace=X")
>> } else {
>>  openshift.create(obj)
>>  }
>>  }
>>  
>> 
>> But this is not ideal and just creates noise. Ideally I simply want create() 
>> in the pipeline to be able to reproduce create() on the command-line.
>> 
>> 
>> 
>>> On 19 Dec 2017, at 11:26, Alan Christie >> > wrote:
>>> 
>>> Hi guys,
>>> 
>>> I have a template that can be successfully processed and the objects 
>>> created using oc from the command-line. The template is supposed to run in 
>>> one namespace (let’s call it Y) but it creates secrets that are placed in 
>>> another namespace/project (let’s call that X). The namespaces are managed 
>>> the same user. Both namespaces exist and the following command when run on 
>>> the command-line is valid and is successful:
>>> 
>>> oc process -f  | oc create -f -
>>> 
>>> The act of processing and creating templates works in the Jenkins pipeline 
>>> except when the template creates objects in different namespaces. When I 
>>> try and reproduce these actions from within a Jenkins pipeline job that is 
>>> using the OpenShift Jenkins Pipeline (DSL) Plugin, i.e. when I do something 
>>> like this…
>>> 
>>> openshift.withCluster("${CLUSTER}") {
>>> openshift.withProject(“${Y}") {
>>> def objs = 
>>> openshift.process('—filename=’)
>>> openshift.create(objs)
>>> }
>>> }
>>> 
>>> I get the following error reported in the Jenkins Job output:
>>> 
>>> err=error: the namespace from the provided object “X" does not match 
>>> the namespace “Y". You must pass '—namespace=X' to perform this operation., 
>>> verb=create
>>> 
>>> How do replicate the actions that appear to be legitimate from the 
>>> command-line but using the Pipeline Plugin? Its error does not make sense. 
>>> Instead the plugin appears to assume that the objects created form the 
>>> template must reside in the namespace in which I am running and therefore 
>>> insists on it.
>>> 
>>> Should I raise an issue on the Plugin project?
>>> 
>>> https://github.com/openshift/jenkins-client-plugin 
>>> 
>>> 
>>> Thank you in advance of any help but, in the meantime I will continue to 
>>> search for a solution.
>>> 
>>> Alan Christie
>>> Informatics Matters
>>> 
>>> 
>> 
>> 
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com 
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev 
>> 
>> 
>> 
> 
> 

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: origin v3.7.0 images at docker.io

2017-12-19 Thread Mateus Caruccio
Sorry I was not specific enougth. I meant images for
origin-metrics-{hawkular-metrics,cassandra,heapster}.
AFAIR there was an issue with auth for hawkular on v3.6...

--
Mateus Caruccio / Master of Puppets
GetupCloud.com
We make the infrastructure invisible
Gartner Cool Vendor 2017

2017-12-19 12:12 GMT-02:00 Clayton Coleman :

> Did I forget to send the email?  We cut a few weeks ago.
>
> On Dec 19, 2017, at 8:46 AM, Mateus Caruccio  com> wrote:
>
> Hey, is there any prevision for when will 3.7.0 be released?
> tnx
>
> --
> Mateus Caruccio / Master of Puppets
> GetupCloud.com
> We make the infrastructure invisible
> Gartner Cool Vendor 2017
>
> 2017-11-21 16:54 GMT-02:00 Clayton Coleman :
>
>> We haven't cut 3.7.0 yet in origin.  Still waiting for final soak
>> determination - there are a few outstanding issues being chased.  I'd urge
>> everyone who wants 3.7.0 to verify that 3.7.0.rc0 works for them.
>>
>> On Tue, Nov 21, 2017 at 1:40 PM, Jason Brooks  wrote:
>>
>>> Can we get v3.7.0 images for openshift/origin?
>>>
>>> See https://hub.docker.com/r/openshift/origin/tags/
>>>
>>> Regards, Jason
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: OpenShift Jenkins Pipeline (DSL) Plugin : erroneous 'incorrect namespace' error from create()?

2017-12-19 Thread Alan Christie
Thanks Justin,

Is it of interest that the plugin’s create() behaves differently to the 
command-line? It just doesn't _feel_ right. I could create an issue in the 
client plugin GitHub project if the consensus is that the behaviour is wrong. 
After all, why does create() care? Its command-line-cousin doesn’t.

At the moment my work-around (inspecting the namespace) and iterating through 
the objects feels more pleasant than using raw.

Alan.

> On 19 Dec 2017, at 14:09, Justin Pierce  wrote:
> 
> Alan - This might be a use case for the openshift.raw API [1]. It will simply 
> pass through any arguments you give it. 
> 
> Best Regards,
> Justin
> [1] https://github.com/openshift/jenkins-client-plugin#i-need-more 
> 
> 
> On Tue, Dec 19, 2017 at 6:57 AM, Alan Christie 
> > 
> wrote:
> I appear to be able to work-around the problem by iterating through the 
> objects created by the call to process() and conditionally setting the 
> namespace, i.e. by doing this…
> 
>   def objs = openshift.process('—filename=’)
>   for (obj in objs) {
>   if (obj.metadata.namespace == “X") {
>   openshift.create(obj, "—namespace=X")
> } else {
>   openshift.create(obj)
>   }
>   }
>  
> 
> But this is not ideal and just creates noise. Ideally I simply want create() 
> in the pipeline to be able to reproduce create() on the command-line.
> 
> 
> 
>> On 19 Dec 2017, at 11:26, Alan Christie > > wrote:
>> 
>> Hi guys,
>> 
>> I have a template that can be successfully processed and the objects created 
>> using oc from the command-line. The template is supposed to run in one 
>> namespace (let’s call it Y) but it creates secrets that are placed in 
>> another namespace/project (let’s call that X). The namespaces are managed 
>> the same user. Both namespaces exist and the following command when run on 
>> the command-line is valid and is successful:
>> 
>>  oc process -f  | oc create -f -
>> 
>> The act of processing and creating templates works in the Jenkins pipeline 
>> except when the template creates objects in different namespaces. When I try 
>> and reproduce these actions from within a Jenkins pipeline job that is using 
>> the OpenShift Jenkins Pipeline (DSL) Plugin, i.e. when I do something like 
>> this…
>> 
>>  openshift.withCluster("${CLUSTER}") {
>>  openshift.withProject(“${Y}") {
>>  def objs = 
>> openshift.process('—filename=’)
>>  openshift.create(objs)
>>  }
>>  }
>> 
>> I get the following error reported in the Jenkins Job output:
>> 
>>  err=error: the namespace from the provided object “X" does not match 
>> the namespace “Y". You must pass '—namespace=X' to perform this operation., 
>> verb=create
>> 
>> How do replicate the actions that appear to be legitimate from the 
>> command-line but using the Pipeline Plugin? Its error does not make sense. 
>> Instead the plugin appears to assume that the objects created form the 
>> template must reside in the namespace in which I am running and therefore 
>> insists on it.
>> 
>> Should I raise an issue on the Plugin project?
>> 
>>  https://github.com/openshift/jenkins-client-plugin 
>> 
>> 
>> Thank you in advance of any help but, in the meantime I will continue to 
>> search for a solution.
>> 
>> Alan Christie
>> Informatics Matters
>> 
>> 
> 
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev 
> 
> 
> 

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: origin v3.7.0 images at docker.io

2017-12-19 Thread Clayton Coleman
Did I forget to send the email?  We cut a few weeks ago.

On Dec 19, 2017, at 8:46 AM, Mateus Caruccio 
wrote:

Hey, is there any prevision for when will 3.7.0 be released?
tnx

--
Mateus Caruccio / Master of Puppets
GetupCloud.com
We make the infrastructure invisible
Gartner Cool Vendor 2017

2017-11-21 16:54 GMT-02:00 Clayton Coleman :

> We haven't cut 3.7.0 yet in origin.  Still waiting for final soak
> determination - there are a few outstanding issues being chased.  I'd urge
> everyone who wants 3.7.0 to verify that 3.7.0.rc0 works for them.
>
> On Tue, Nov 21, 2017 at 1:40 PM, Jason Brooks  wrote:
>
>> Can we get v3.7.0 images for openshift/origin?
>>
>> See https://hub.docker.com/r/openshift/origin/tags/
>>
>> Regards, Jason
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: origin v3.7.0 images at docker.io

2017-12-19 Thread Tobias Florek
Hi!

# skopeo inspect docker://openshift/origin:v3.7.0

tells me, that 3.7.0 is already on dockerhub.

Cheers,
 Tobias Florek

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: OpenShift Jenkins Pipeline (DSL) Plugin : erroneous 'incorrect namespace' error from create()?

2017-12-19 Thread Justin Pierce
Alan - This might be a use case for the openshift.raw API [1]. It will
simply pass through any arguments you give it.

Best Regards,
Justin
[1] https://github.com/openshift/jenkins-client-plugin#i-need-more

On Tue, Dec 19, 2017 at 6:57 AM, Alan Christie <
achris...@informaticsmatters.com> wrote:

> I appear to be able to work-around the problem by iterating through the
> objects created by the call to process() and conditionally setting the
> namespace, i.e. by doing this…
>
> def objs = openshift.process('—filename=’)
> for (obj in objs) {
> if (obj.metadata.namespace == “X") {
> openshift.create(obj, "—namespace=X")
> } else {
>   openshift.create(obj)
> }
> }
>
>
> But this is not ideal and just creates noise. Ideally I simply want
> create() in the pipeline to be able to reproduce create() on the
> command-line.
>
>
>
> On 19 Dec 2017, at 11:26, Alan Christie 
> wrote:
>
> Hi guys,
>
> I have a template that can be successfully processed and the objects
> created using oc from the command-line. The template is supposed to run in
> one namespace (let’s call it *Y*) but it creates secrets that are placed
> in another namespace/project (let’s call that *X*). The namespaces are
> managed the same user. Both namespaces exist and the following command when
> run on the command-line is valid and is successful:
>
> oc process -f  | oc create -f -
>
> The act of processing and creating templates works in the Jenkins pipeline
> except when the template creates objects in different namespaces. When I
> try and reproduce these actions from within a Jenkins pipeline job that is
> using the OpenShift Jenkins Pipeline (DSL) Plugin, i.e. when I do something
> like this…
>
> openshift.withCluster("${CLUSTER}") {
> openshift.withProject(“${Y}") {
> def objs = openshift.process('—filename=’)
> openshift.create(objs)
> }
> }
>
> I get the following error reported in the Jenkins Job output:
>
> err=error: the namespace from the provided object “*X*" does not match
> the namespace “*Y*". You must pass '—namespace=*X*' to perform this
> operation., verb=create
>
> How do replicate the actions that appear to be legitimate from the
> command-line but using the Pipeline Plugin? Its error does not make sense.
> Instead the plugin appears to assume that the objects created form the
> template must reside in the namespace in which I am running and therefore
> insists on it.
>
> Should I raise an issue on the Plugin project?
>
> https://github.com/openshift/jenkins-client-plugin
>
> Thank you in advance of any help but, in the meantime I will continue to
> search for a solution.
>
> Alan Christie
> Informatics Matters
>
>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: SCC privileged not applying

2017-12-19 Thread Jordan Liggitt
> On Dec 19, 2017, at 1:49 AM, Weiwei Jiang  wrote:
>
> But the scc is trying to verify the creater account(you can see this with 
> audit enabled), and should be daemonset-controller or something like this but 
> not the given serviceaccount).

That's not accurate. You can give the SCC permissions to either the
creating user (in the case of a daemonset, this is the daemonset
controller) and/or to the service account of this pod.

You should avoid giving SCC permissions to the pod creating
controllers, since that enables any user that can create a daemonset
to make use of those permissions via the controller.

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: SCC privileged not applying

2017-12-19 Thread Mateus Caruccio
Makes sense. Thanks for your clarification ;)

--
Mateus Caruccio / Master of Puppets
GetupCloud.com
We make the infrastructure invisible
Gartner Cool Vendor 2017

2017-12-19 4:48 GMT-02:00 Weiwei Jiang :

> Hi:
>
> I think you make some misunderstanding with OpenShift.
>
> Actually you create a daemonset with a specific serviceaccount you created
> which is granted with the SCC privileged, right?
> But the scc is trying to verify the creater account(you can see this with
> audit enabled), and should be daemonset-controller or something like this
> but not the given serviceaccount).
> So you grant the new-relic account, but the creater is
> daemonset-controller(just put it here, maybe this is also not the right
> serviceaccount to create the target pod), so got this issue.
>
> And back to your scenario, I have no better suggestion if you insistently
> use daemonset to create the pod.
>
> You can pick up the pod template from the daemonset to just create the pod
> directly and grant the scc with your user(`oc whoami`) but will loss the
> daemonset features.
>
>
> Regards!
>
> On Tue, Dec 19, 2017 at 3:01 AM Mateus Caruccio <
> mateus.caruc...@getupcloud.com> wrote:
>
>> There is this daemonset which needs host access. I've created a
>> namespace, added `privileged` scc to a new serviceaccount and set pod to
>> run with that SA.
>>
>> The problem is openshift is not applying the privileged SCC to my
>> serviceAccount.
>>
>> *$ oc get ev*
>> LASTSEEN   FIRSTSEEN   COUNT NAME KINDSUBOBJECT
>> TYPE  REASON SOURCE   MESSAGE
>> 17s17s 25newrelic-agent   DaemonSet
>> Warning   FailedCreate   daemon-set   Error creating: pods
>> "newrelic-agent-" is forbidden: unable to validate against any security
>> context constraint: [provider restricted: .spec.securityContext.hostNetwork:
>> Invalid value: true: Host network is not allowed to be used provider
>> restricted: .spec.securityContext.hostPID: Invalid value: true: Host PID is
>> not allowed to be used provider restricted: .spec.securityContext.hostIPC:
>> Invalid value: true: Host IPC is not allowed to be used provider
>> restricted: .spec.containers[0].securityContext.privileged: Invalid
>> value: true: Privileged containers are not allowed provider restricted:
>> .spec.containers[0].securityContext.volumes[1]: Invalid value:
>> "hostPath": hostPath volumes are not allowed to be used provider
>> restricted: .spec.containers[0].securityContext.volumes[2]: Invalid
>> value: "hostPath": hostPath volumes are not allowed to be used provider
>> restricted: .spec.containers[0].securityContext.volumes[3]: Invalid
>> value: "hostPath": hostPath volumes are not allowed to be used provider
>> restricted: .spec.containers[0].securityContext.volumes[4]: Invalid
>> value: "hostPath": hostPath volumes are not allowed to be used provider
>> restricted: .spec.containers[0].securityContext.hostNetwork: Invalid
>> value: true: Host network is not allowed to be used provider restricted:
>> .spec.containers[0].securityContext.hostPID: Invalid value: true: Host
>> PID is not allowed to be used provider restricted: 
>> .spec.containers[0].securityContext.hostIPC:
>> Invalid value: true: Host IPC is not allowed to be used]
>>
>>
>> This is my config:
>>
>>
>> *$ oc version*
>> oc v3.6.0+c4dd4cf
>> kubernetes v1.6.1+5115d708d7
>> features: Basic-Auth GSSAPI Kerberos SPNEGO
>>
>> Server https://[REDACTED]
>> openshift v3.6.0+c4dd4cf
>> kubernetes v1.6.1+5115d708d7
>>
>>
>> *$ oc whoami*
>> system:admin
>>
>>
>> *$ oc get ds -o yaml -n new-relic*
>> apiVersion: v1
>> items:
>> - apiVersion: extensions/v1beta1
>>   kind: DaemonSet
>>   metadata:
>> creationTimestamp: 2017-12-18T18:20:42Z
>> generation: 1
>> labels:
>>   app: newrelic-agent
>>   tier: monitoring
>>   version: v1
>> name: newrelic-agent
>> namespace: new-relic
>> resourceVersion: "9280118"
>> selfLink: /apis/extensions/v1beta1/namespaces/new-relic/
>> daemonsets/newrelic-agent
>> uid: 286ed3c9-e420-11e7-aa46-000af7b3efa4
>>   spec:
>> selector:
>>   matchLabels:
>> name: newrelic
>> template:
>>   metadata:
>> creationTimestamp: null
>> labels:
>>   name: newrelic
>>   spec:
>> containers:
>> - command:
>>   - bash
>>   - -c
>>   - source /etc/kube-newrelic/config && /usr/sbin/nrsysmond -E -F
>>   env:
>>   - name: NRSYSMOND_logfile
>> value: /var/log/nrsysmond.log
>>   image: newrelic/nrsysmond
>>   imagePullPolicy: Always
>>   name: newrelic
>>   resources:
>> requests:
>>   cpu: 150m
>>   securityContext:
>> privileged: true
>>   terminationMessagePath: /dev/termination-log
>>   terminationMessagePolicy: File
>>   volumeMounts:
>>   - mountPath: /etc/kube-newrelic
>> 

Re: origin v3.7.0 images at docker.io

2017-12-19 Thread Mateus Caruccio
Hey, is there any prevision for when will 3.7.0 be released?
tnx

--
Mateus Caruccio / Master of Puppets
GetupCloud.com
We make the infrastructure invisible
Gartner Cool Vendor 2017

2017-11-21 16:54 GMT-02:00 Clayton Coleman :

> We haven't cut 3.7.0 yet in origin.  Still waiting for final soak
> determination - there are a few outstanding issues being chased.  I'd urge
> everyone who wants 3.7.0 to verify that 3.7.0.rc0 works for them.
>
> On Tue, Nov 21, 2017 at 1:40 PM, Jason Brooks  wrote:
>
>> Can we get v3.7.0 images for openshift/origin?
>>
>> See https://hub.docker.com/r/openshift/origin/tags/
>>
>> Regards, Jason
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


Re: OpenShift Jenkins Pipeline (DSL) Plugin : erroneous 'incorrect namespace' error from create()?

2017-12-19 Thread Alan Christie
I appear to be able to work-around the problem by iterating through the objects 
created by the call to process() and conditionally setting the namespace, i.e. 
by doing this…

def objs = openshift.process('—filename=’)
for (obj in objs) {
if (obj.metadata.namespace == “X") {
openshift.create(obj, "—namespace=X")
} else {
openshift.create(obj)
}
}
 

But this is not ideal and just creates noise. Ideally I simply want create() in 
the pipeline to be able to reproduce create() on the command-line.


> On 19 Dec 2017, at 11:26, Alan Christie  
> wrote:
> 
> Hi guys,
> 
> I have a template that can be successfully processed and the objects created 
> using oc from the command-line. The template is supposed to run in one 
> namespace (let’s call it Y) but it creates secrets that are placed in another 
> namespace/project (let’s call that X). The namespaces are managed the same 
> user. Both namespaces exist and the following command when run on the 
> command-line is valid and is successful:
> 
>   oc process -f  | oc create -f -
> 
> The act of processing and creating templates works in the Jenkins pipeline 
> except when the template creates objects in different namespaces. When I try 
> and reproduce these actions from within a Jenkins pipeline job that is using 
> the OpenShift Jenkins Pipeline (DSL) Plugin, i.e. when I do something like 
> this…
> 
>   openshift.withCluster("${CLUSTER}") {
>   openshift.withProject(“${Y}") {
>   def objs = 
> openshift.process('—filename=’)
>   openshift.create(objs)
>   }
>   }
> 
> I get the following error reported in the Jenkins Job output:
> 
>   err=error: the namespace from the provided object “X" does not match 
> the namespace “Y". You must pass '—namespace=X' to perform this operation., 
> verb=create
> 
> How do replicate the actions that appear to be legitimate from the 
> command-line but using the Pipeline Plugin? Its error does not make sense. 
> Instead the plugin appears to assume that the objects created form the 
> template must reside in the namespace in which I am running and therefore 
> insists on it.
> 
> Should I raise an issue on the Plugin project?
> 
>   https://github.com/openshift/jenkins-client-plugin 
> 
> 
> Thank you in advance of any help but, in the meantime I will continue to 
> search for a solution.
> 
> Alan Christie
> Informatics Matters
> 
> 

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


OpenShift Jenkins Pipeline (DSL) Plugin : erroneous 'incorrect namespace' error from create()?

2017-12-19 Thread Alan Christie
Hi guys,

I have a template that can be successfully processed and the objects created 
using oc from the command-line. The template is supposed to run in one 
namespace (let’s call it Y) but it creates secrets that are placed in another 
namespace/project (let’s call that X). The namespaces are managed the same 
user. Both namespaces exist and the following command when run on the 
command-line is valid and is successful:

oc process -f  | oc create -f -

The act of processing and creating templates works in the Jenkins pipeline 
except when the template creates objects in different namespaces. When I try 
and reproduce these actions from within a Jenkins pipeline job that is using 
the OpenShift Jenkins Pipeline (DSL) Plugin, i.e. when I do something like this…

openshift.withCluster("${CLUSTER}") {
openshift.withProject(“${Y}") {
def objs = 
openshift.process('—filename=’)
openshift.create(objs)
}
}

I get the following error reported in the Jenkins Job output:

err=error: the namespace from the provided object “X" does not match 
the namespace “Y". You must pass '—namespace=X' to perform this operation., 
verb=create

How do replicate the actions that appear to be legitimate from the command-line 
but using the Pipeline Plugin? Its error does not make sense. Instead the 
plugin appears to assume that the objects created form the template must reside 
in the namespace in which I am running and therefore insists on it.

Should I raise an issue on the Plugin project?

https://github.com/openshift/jenkins-client-plugin

Thank you in advance of any help but, in the meantime I will continue to search 
for a solution.

Alan Christie
Informatics Matters


___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev