How to improve pod scheduling

2018-05-23 Thread Lionel Orellana
Hi All,

We have 20 worker nodes all with the same labels (they all have the same
specs). Our pods don't have any node selectors so all nodes are available
to all pods.

What we are seeing is the scheduler constantly placing pods on nodes that
are already heavily usitised (in terms of memory and/or cpu) while other
nodes have plenty of capacity.

We have places resource request on some pods and they continue to be placed
on the busy nodes.

How can we help the scheduler make better decisions?

-bash-4.2$ oc version
oc v3.6.0+c4dd4cf
kubernetes v1.6.1+5115d708d7
features: Basic-Auth GSSAPI Kerberos SPNEGO

openshift v3.6.173.0.21
kubernetes v1.6.1+5115d708d7



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


Re: Build pod already exists

2018-03-02 Thread Lionel Orellana
For anyone that comes across this issue here, it is likely it was related
to ntp. There is a bugzilla for it:
https://bugzilla.redhat.com/show_bug.cgi?id=1547551

On 29 January 2018 at 06:12, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Sun, Jan 28, 2018 at 6:05 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Thanks Ben.
>>
>> I can reproduce it with the nodejs and wildfly bjild configs directly off
>> the catalog.
>>
>
> and you haven't created those buildconfigs previously and then deleted
> them, within that project?  This is the first time you're creating the
> buildconfig in the project?
>
>
>>
>> My first thought was that the network issue was causing the build pod to
>> be terminated and a second one is being created before the first one dies.
>> Is that a possibility?
>>
>
> I don't think so, once we create a pod for a given build we consider it
> done and shouldn't be creating another one, but the logs should shed some
> light on that.
>
>
>> I will get the logs tomorrow.
>>
>> On Sun, 28 Jan 2018 at 1:51 pm, Ben Parees <bpar...@redhat.com> wrote:
>>
>>> On Sat, Jan 27, 2018 at 4:06 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm seeing an random error when running builds. Some builds fail very
>>>> quickly with "build pod already exists". This is happening with a number of
>>>> build configs and seems to occur when more than one build from different
>>>> build configs are running at the same time.
>>>>
>>>
>>> This can happen if you "reset" the build sequence number in your
>>> buildconfig (buildconfig.status.latestversion).  Are you recreating
>>> buildconfigs that may have previously existed and run builds, or editing
>>> the buildconfig in a way that might be reseting the lastversion field to an
>>> older value?
>>>
>>> Are you able to confirm whether or not a pod does exist for that build?
>>> The build pod name will be in the form like "buildconfigname-buildnumber-b
>>> uild"
>>>
>>> If you're able to recreate this consistently(assuming you're sure it's
>>> not a case of you having recreated an old buildconfig or reset the
>>> buildconfig lastversion sequence value), enabling level 4 logging in your
>>> master and reproducing it and then providing us with the logs would be
>>> helpful to trace what is happening.
>>>
>>>
>>>
>>>>
>>>> There is a possibly related error in one of the nodes:
>>>>
>>>> Jan 28 07:26:39  atomic-openshift-node[10121]: W0128 07:26:39.735522
>>>> 10848 docker_sandbox.go:266] NetworkPlugin cni failed on the stat
>>>> us hook for pod "nodejs-26-build_bimorl": Unexpected command output
>>>> nsenter: cannot open : No such file or directory
>>>> Jan 28 07:26:39 atomic-openshift-node[10121]: with error: exit status 1
>>>>
>>>
>>> This shouldn't be related to issues with pod creation (since this error
>>> wouldn't occur until after the pod is created and attempting to run on a
>>> node), but it's definitely something you'll want to sort out.  I've CCed
>>> our networking lead into this thread.
>>>
>>>
>>>
>>>>
>>>> -bash-4.2$ oc version
>>>> oc v3.6.0+c4dd4cf
>>>> kubernetes v1.6.1+5115d708d7
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Lionel.
>>>>
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>> Ben Parees | OpenShift
>>>
>>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Build pod already exists

2018-01-28 Thread Lionel Orellana
Thanks Ben.

I can reproduce it with the nodejs and wildfly bjild configs directly off
the catalog.

My first thought was that the network issue was causing the build pod to be
terminated and a second one is being created before the first one dies. Is
that a possibility?

I will get the logs tomorrow.
On Sun, 28 Jan 2018 at 1:51 pm, Ben Parees <bpar...@redhat.com> wrote:

> On Sat, Jan 27, 2018 at 4:06 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm seeing an random error when running builds. Some builds fail very
>> quickly with "build pod already exists". This is happening with a number of
>> build configs and seems to occur when more than one build from different
>> build configs are running at the same time.
>>
>
> This can happen if you "reset" the build sequence number in your
> buildconfig (buildconfig.status.latestversion).  Are you recreating
> buildconfigs that may have previously existed and run builds, or editing
> the buildconfig in a way that might be reseting the lastversion field to an
> older value?
>
> Are you able to confirm whether or not a pod does exist for that build?
> The build pod name will be in the form like
> "buildconfigname-buildnumber-build"
>
> If you're able to recreate this consistently(assuming you're sure it's not
> a case of you having recreated an old buildconfig or reset the buildconfig
> lastversion sequence value), enabling level 4 logging in your master and
> reproducing it and then providing us with the logs would be helpful to
> trace what is happening.
>
>
>
>>
>> There is a possibly related error in one of the nodes:
>>
>> Jan 28 07:26:39  atomic-openshift-node[10121]: W0128 07:26:39.735522
>> 10848 docker_sandbox.go:266] NetworkPlugin cni failed on the stat
>> us hook for pod "nodejs-26-build_bimorl": Unexpected command output
>> nsenter: cannot open : No such file or directory
>> Jan 28 07:26:39 atomic-openshift-node[10121]: with error: exit status 1
>>
>
> This shouldn't be related to issues with pod creation (since this error
> wouldn't occur until after the pod is created and attempting to run on a
> node), but it's definitely something you'll want to sort out.  I've CCed
> our networking lead into this thread.
>
>
>
>>
>> -bash-4.2$ oc version
>> oc v3.6.0+c4dd4cf
>> kubernetes v1.6.1+5115d708d7
>>
>> Any ideas?
>>
>> Thanks
>>
>>
>> Lionel.
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-17 Thread Lionel Orellana
It works if I mount the secret on /etc/pki/tls/certs.

Yeh doco on this is non-existent. I've been struggling with this all day
but now that you say it a PV with the full ca-trust dir sounds obvious.

On 18 November 2017 at 17:52, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Sat, Nov 18, 2017 at 1:31 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> It doesn't look like putting the ca in /etc/pki/ca-trust/source/anchors
>> is enough without running update-ca-trust
>>
>
> yeah that makes sense and unfortunately makes it difficult if you don't
> mount your ca-trust via a PV since you'll lose the changes whenever your
> registry restarts.
>
> Would you mind opening an issue for us to add some docs(at a minimum)
> around this since it seems like they are lacking?
>
>
>>
>> On 18 November 2017 at 15:40, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> Inside the registry, curl with --cacert pointing to
>>> /etc/pki/ca-trust/source/anchors/.crt works.
>>>
>>> On 18 November 2017 at 15:11, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> I created a secret with the remote ca, mounted it on the registry at
>>>> /etc/pki/ca-trust/source/anchor. The registry still says "certificate
>>>> signed by unknown authority".
>>>>
>>>> On 17 November 2017 at 23:57, Ben Parees <bpar...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 17, 2017 at 12:17 AM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks Ben, that makes sense.  How do I add remote CAs to the
>>>>>> registry though?
>>>>>>
>>>>>
>>>>> Similar to what is described here to add certs to the registry:
>>>>> https://docs.openshift.org/latest/install_config/registry/se
>>>>> curing_and_exposing_registry.html#securing-the-registry
>>>>>
>>>>> (mount the ca.crt into the system ca cert location within the pod, it
>>>>> should be picked up automatically).
>>>>>
>>>>>
>>>>>
>>>>>> On 17 November 2017 at 15:08, Ben Parees <bpar...@redhat.com> wrote:
>>>>>>
>>>>>>> The registry CAs are distinct from the image import controller CA.
>>>>>>> They are two different processes running in two different environments.
>>>>>>>
>>>>>>>
>>>>>>> Ben Parees | OpenShift
>>>>>>>
>>>>>>> On Nov 16, 2017 10:58 PM, "Lionel Orellana" <lione...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Looking at the registry logs, it's not happy with the remote
>>>>>>>> registry cert.
>>>>>>>>
>>>>>>>> time="2017-11-17T03:53:46.591715267Z" level=error msg="response
>>>>>>>> completed with error" err.code="manifest unknown" err.detail=" x509:
>>>>>>>> certificate signed by unknown authority"
>>>>>>>>
>>>>>>>> Given that oc import-image works I was expecting the registry to
>>>>>>>> trust the same ca's.
>>>>>>>>
>>>>>>>> On 17 November 2017 at 12:01, Ben Parees <bpar...@redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 16, 2017 at 7:57 PM, Lionel Orellana <
>>>>>>>>> lione...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Is pullthrough enabled on your registry?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> "When performing pullthrough, the registry will use pull
>>>>>>>>>>> credentials found in the project associated with the image stream 
>>>>>>>>>>> tag that
>>>>>>>>>>> is being referenced"
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm deploying in the same p

Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-17 Thread Lionel Orellana
It doesn't look like putting the ca in /etc/pki/ca-trust/source/anchors is
enough without running update-ca-trust

On 18 November 2017 at 15:40, Lionel Orellana <lione...@gmail.com> wrote:

> Inside the registry, curl with --cacert pointing to
> /etc/pki/ca-trust/source/anchors/.crt works.
>
> On 18 November 2017 at 15:11, Lionel Orellana <lione...@gmail.com> wrote:
>
>> I created a secret with the remote ca, mounted it on the registry at
>> /etc/pki/ca-trust/source/anchor. The registry still says "certificate
>> signed by unknown authority".
>>
>> On 17 November 2017 at 23:57, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Fri, Nov 17, 2017 at 12:17 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Thanks Ben, that makes sense.  How do I add remote CAs to the registry
>>>> though?
>>>>
>>>
>>> Similar to what is described here to add certs to the registry:
>>> https://docs.openshift.org/latest/install_config/registry/se
>>> curing_and_exposing_registry.html#securing-the-registry
>>>
>>> (mount the ca.crt into the system ca cert location within the pod, it
>>> should be picked up automatically).
>>>
>>>
>>>
>>>> On 17 November 2017 at 15:08, Ben Parees <bpar...@redhat.com> wrote:
>>>>
>>>>> The registry CAs are distinct from the image import controller CA.
>>>>> They are two different processes running in two different environments.
>>>>>
>>>>>
>>>>> Ben Parees | OpenShift
>>>>>
>>>>> On Nov 16, 2017 10:58 PM, "Lionel Orellana" <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Looking at the registry logs, it's not happy with the remote registry
>>>>>> cert.
>>>>>>
>>>>>> time="2017-11-17T03:53:46.591715267Z" level=error msg="response
>>>>>> completed with error" err.code="manifest unknown" err.detail=" x509:
>>>>>> certificate signed by unknown authority"
>>>>>>
>>>>>> Given that oc import-image works I was expecting the registry to
>>>>>> trust the same ca's.
>>>>>>
>>>>>> On 17 November 2017 at 12:01, Ben Parees <bpar...@redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 16, 2017 at 7:57 PM, Lionel Orellana <lione...@gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Is pullthrough enabled on your registry?
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> "When performing pullthrough, the registry will use pull
>>>>>>>>> credentials found in the project associated with the image stream tag 
>>>>>>>>> that
>>>>>>>>> is being referenced"
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm deploying in the same project where the image stream is. I have
>>>>>>>> a dockercfg secret in the project with credentials for the remote 
>>>>>>>> registry.
>>>>>>>> I linked that secret to the deployment as pull secret. It works when
>>>>>>>> remotePolicy is Source so I know the credentials are Ok. But how does 
>>>>>>>> the
>>>>>>>> registry find the pull credentials to use? I assume it looks for the 
>>>>>>>> server
>>>>>>>> name in the dockercfg secret?
>>>>>>>>
>>>>>>>
>>>>>>> yes.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17 November 2017 at 10:01, Ben Parees <bpar...@redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 16, 2017 at 5:36 PM, Lionel Orellana <
>>>>>>>>> lione...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>&g

Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-17 Thread Lionel Orellana
Inside the registry, curl with --cacert pointing to
/etc/pki/ca-trust/source/anchors/.crt works.

On 18 November 2017 at 15:11, Lionel Orellana <lione...@gmail.com> wrote:

> I created a secret with the remote ca, mounted it on the registry at
> /etc/pki/ca-trust/source/anchor. The registry still says "certificate
> signed by unknown authority".
>
> On 17 November 2017 at 23:57, Ben Parees <bpar...@redhat.com> wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 12:17 AM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> Thanks Ben, that makes sense.  How do I add remote CAs to the registry
>>> though?
>>>
>>
>> Similar to what is described here to add certs to the registry:
>> https://docs.openshift.org/latest/install_config/registry/
>> securing_and_exposing_registry.html#securing-the-registry
>>
>> (mount the ca.crt into the system ca cert location within the pod, it
>> should be picked up automatically).
>>
>>
>>
>>> On 17 November 2017 at 15:08, Ben Parees <bpar...@redhat.com> wrote:
>>>
>>>> The registry CAs are distinct from the image import controller CA. They
>>>> are two different processes running in two different environments.
>>>>
>>>>
>>>> Ben Parees | OpenShift
>>>>
>>>> On Nov 16, 2017 10:58 PM, "Lionel Orellana" <lione...@gmail.com> wrote:
>>>>
>>>>> Looking at the registry logs, it's not happy with the remote registry
>>>>> cert.
>>>>>
>>>>> time="2017-11-17T03:53:46.591715267Z" level=error msg="response
>>>>> completed with error" err.code="manifest unknown" err.detail=" x509:
>>>>> certificate signed by unknown authority"
>>>>>
>>>>> Given that oc import-image works I was expecting the registry to trust
>>>>> the same ca's.
>>>>>
>>>>> On 17 November 2017 at 12:01, Ben Parees <bpar...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 16, 2017 at 7:57 PM, Lionel Orellana <lione...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Is pullthrough enabled on your registry?
>>>>>>>
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>> "When performing pullthrough, the registry will use pull credentials
>>>>>>>> found in the project associated with the image stream tag that is being
>>>>>>>> referenced"
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'm deploying in the same project where the image stream is. I have
>>>>>>> a dockercfg secret in the project with credentials for the remote 
>>>>>>> registry.
>>>>>>> I linked that secret to the deployment as pull secret. It works when
>>>>>>> remotePolicy is Source so I know the credentials are Ok. But how does 
>>>>>>> the
>>>>>>> registry find the pull credentials to use? I assume it looks for the 
>>>>>>> server
>>>>>>> name in the dockercfg secret?
>>>>>>>
>>>>>>
>>>>>> yes.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 17 November 2017 at 10:01, Ben Parees <bpar...@redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 16, 2017 at 5:36 PM, Lionel Orellana <
>>>>>>>> lione...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I imported a remote image and set  referencePolicy.type to Local
>>>>>>>>> in the resulting tag. When I try to deploy an pod using this image 
>>>>>>>>> stream
>>>>>>>>> tag I get "rpc error: code = 2 desc = manifest unknown: manifest
>>>>>>>>> unknown".
>>>>>>>>>
>>>>>>>>> If I change the referencePolicy type to Source then the pod pulls
>>>>>>>>> the image fine from the remote registry. But this requires linking a 
>>>>>>>>> pull
>>>>>>>>> secret to the deployment which is an extra step I could do without. I
>>>>>>>>> thought I would get around that by referencing the Local image.
>>>>>>>>>
>>>>>>>>> How do I pull the remote image when referencePolicy is Local?
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Is pullthrough enabled on your registry?
>>>>>>>> https://docs.openshift.org/latest/install_config/registry/ex
>>>>>>>> tended_registry_configuration.html#middleware-repository-pul
>>>>>>>> lthrough
>>>>>>>>
>>>>>>>> also:
>>>>>>>> "When performing pullthrough, the registry will use pull
>>>>>>>> credentials found in the project associated with the image stream tag 
>>>>>>>> that
>>>>>>>> is being referenced. "
>>>>>>>>
>>>>>>>> So if your imagestream is in a different project, you need to make
>>>>>>>> sure the credentials are in the right place.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> users mailing list
>>>>>>>>> users@lists.openshift.redhat.com
>>>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ben Parees | OpenShift
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ben Parees | OpenShift
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>> --
>> Ben Parees | OpenShift
>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-17 Thread Lionel Orellana
I created a secret with the remote ca, mounted it on the registry at
/etc/pki/ca-trust/source/anchor.
The registry still says "certificate signed by unknown authority".

On 17 November 2017 at 23:57, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Fri, Nov 17, 2017 at 12:17 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Thanks Ben, that makes sense.  How do I add remote CAs to the registry
>> though?
>>
>
> Similar to what is described here to add certs to the registry:
> https://docs.openshift.org/latest/install_config/registry/securing_and_
> exposing_registry.html#securing-the-registry
>
> (mount the ca.crt into the system ca cert location within the pod, it
> should be picked up automatically).
>
>
>
>> On 17 November 2017 at 15:08, Ben Parees <bpar...@redhat.com> wrote:
>>
>>> The registry CAs are distinct from the image import controller CA. They
>>> are two different processes running in two different environments.
>>>
>>>
>>> Ben Parees | OpenShift
>>>
>>> On Nov 16, 2017 10:58 PM, "Lionel Orellana" <lione...@gmail.com> wrote:
>>>
>>>> Looking at the registry logs, it's not happy with the remote registry
>>>> cert.
>>>>
>>>> time="2017-11-17T03:53:46.591715267Z" level=error msg="response
>>>> completed with error" err.code="manifest unknown" err.detail=" x509:
>>>> certificate signed by unknown authority"
>>>>
>>>> Given that oc import-image works I was expecting the registry to trust
>>>> the same ca's.
>>>>
>>>> On 17 November 2017 at 12:01, Ben Parees <bpar...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 16, 2017 at 7:57 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Is pullthrough enabled on your registry?
>>>>>>
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> "When performing pullthrough, the registry will use pull credentials
>>>>>>> found in the project associated with the image stream tag that is being
>>>>>>> referenced"
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm deploying in the same project where the image stream is. I have
>>>>>> a dockercfg secret in the project with credentials for the remote 
>>>>>> registry.
>>>>>> I linked that secret to the deployment as pull secret. It works when
>>>>>> remotePolicy is Source so I know the credentials are Ok. But how does the
>>>>>> registry find the pull credentials to use? I assume it looks for the 
>>>>>> server
>>>>>> name in the dockercfg secret?
>>>>>>
>>>>>
>>>>> yes.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 17 November 2017 at 10:01, Ben Parees <bpar...@redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 16, 2017 at 5:36 PM, Lionel Orellana <lione...@gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I imported a remote image and set  referencePolicy.type to Local in
>>>>>>>> the resulting tag. When I try to deploy an pod using this image stream 
>>>>>>>> tag
>>>>>>>> I get "rpc error: code = 2 desc = manifest unknown: manifest
>>>>>>>> unknown".
>>>>>>>>
>>>>>>>> If I change the referencePolicy type to Source then the pod pulls
>>>>>>>> the image fine from the remote registry. But this requires linking a 
>>>>>>>> pull
>>>>>>>> secret to the deployment which is an extra step I could do without. I
>>>>>>>> thought I would get around that by referencing the Local image.
>>>>>>>>
>>>>>>>> How do I pull the remote image when referencePolicy is Local?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is pullthrough enabled on your registry?
>>>>>>> https://docs.openshift.org/latest/install_config/registry/ex
>>>>>>> tended_registry_configuration.html#middleware-repository-pullthrough
>>>>>>>
>>>>>>> also:
>>>>>>> "When performing pullthrough, the registry will use pull credentials
>>>>>>> found in the project associated with the image stream tag that is being
>>>>>>> referenced. "
>>>>>>>
>>>>>>> So if your imagestream is in a different project, you need to make
>>>>>>> sure the credentials are in the right place.
>>>>>>>
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ___
>>>>>>>> users mailing list
>>>>>>>> users@lists.openshift.redhat.com
>>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ben Parees | OpenShift
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ben Parees | OpenShift
>>>>>
>>>>>
>>>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-16 Thread Lionel Orellana
Thanks Ben, that makes sense.  How do I add remote CAs to the registry
though?

On 17 November 2017 at 15:08, Ben Parees <bpar...@redhat.com> wrote:

> The registry CAs are distinct from the image import controller CA. They
> are two different processes running in two different environments.
>
>
> Ben Parees | OpenShift
>
> On Nov 16, 2017 10:58 PM, "Lionel Orellana" <lione...@gmail.com> wrote:
>
>> Looking at the registry logs, it's not happy with the remote registry
>> cert.
>>
>> time="2017-11-17T03:53:46.591715267Z" level=error msg="response
>> completed with error" err.code="manifest unknown" err.detail=" x509:
>> certificate signed by unknown authority"
>>
>> Given that oc import-image works I was expecting the registry to trust
>> the same ca's.
>>
>> On 17 November 2017 at 12:01, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Nov 16, 2017 at 7:57 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Is pullthrough enabled on your registry?
>>>>
>>>>
>>>> Yes.
>>>>
>>>> "When performing pullthrough, the registry will use pull credentials
>>>>> found in the project associated with the image stream tag that is being
>>>>> referenced"
>>>>>
>>>>
>>>>
>>>> I'm deploying in the same project where the image stream is. I have
>>>> a dockercfg secret in the project with credentials for the remote registry.
>>>> I linked that secret to the deployment as pull secret. It works when
>>>> remotePolicy is Source so I know the credentials are Ok. But how does the
>>>> registry find the pull credentials to use? I assume it looks for the server
>>>> name in the dockercfg secret?
>>>>
>>>
>>> yes.
>>>
>>>
>>>>
>>>>
>>>> On 17 November 2017 at 10:01, Ben Parees <bpar...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 16, 2017 at 5:36 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I imported a remote image and set  referencePolicy.type to Local in
>>>>>> the resulting tag. When I try to deploy an pod using this image stream 
>>>>>> tag
>>>>>> I get "rpc error: code = 2 desc = manifest unknown: manifest
>>>>>> unknown".
>>>>>>
>>>>>> If I change the referencePolicy type to Source then the pod pulls the
>>>>>> image fine from the remote registry. But this requires linking a pull
>>>>>> secret to the deployment which is an extra step I could do without. I
>>>>>> thought I would get around that by referencing the Local image.
>>>>>>
>>>>>> How do I pull the remote image when referencePolicy is Local?
>>>>>>
>>>>>
>>>>>
>>>>> Is pullthrough enabled on your registry?
>>>>> https://docs.openshift.org/latest/install_config/registry/ex
>>>>> tended_registry_configuration.html#middleware-repository-pullthrough
>>>>>
>>>>> also:
>>>>> "When performing pullthrough, the registry will use pull credentials
>>>>> found in the project associated with the image stream tag that is being
>>>>> referenced. "
>>>>>
>>>>> So if your imagestream is in a different project, you need to make
>>>>> sure the credentials are in the right place.
>>>>>
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> users mailing list
>>>>>> users@lists.openshift.redhat.com
>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ben Parees | OpenShift
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ben Parees | OpenShift
>>>
>>>
>>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-16 Thread Lionel Orellana
Looking at the registry logs, it's not happy with the remote registry cert.

time="2017-11-17T03:53:46.591715267Z" level=error msg="response completed
with error" err.code="manifest unknown" err.detail=" x509: certificate
signed by unknown authority"

Given that oc import-image works I was expecting the registry to trust the
same ca's.

On 17 November 2017 at 12:01, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Thu, Nov 16, 2017 at 7:57 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Is pullthrough enabled on your registry?
>>
>>
>> Yes.
>>
>> "When performing pullthrough, the registry will use pull credentials
>>> found in the project associated with the image stream tag that is being
>>> referenced"
>>>
>>
>>
>> I'm deploying in the same project where the image stream is. I have
>> a dockercfg secret in the project with credentials for the remote registry.
>> I linked that secret to the deployment as pull secret. It works when
>> remotePolicy is Source so I know the credentials are Ok. But how does the
>> registry find the pull credentials to use? I assume it looks for the server
>> name in the dockercfg secret?
>>
>
> yes.
>
>
>>
>>
>> On 17 November 2017 at 10:01, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Nov 16, 2017 at 5:36 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I imported a remote image and set  referencePolicy.type to Local in the
>>>> resulting tag. When I try to deploy an pod using this image stream tag I
>>>> get "rpc error: code = 2 desc = manifest unknown: manifest unknown".
>>>>
>>>> If I change the referencePolicy type to Source then the pod pulls the
>>>> image fine from the remote registry. But this requires linking a pull
>>>> secret to the deployment which is an extra step I could do without. I
>>>> thought I would get around that by referencing the Local image.
>>>>
>>>> How do I pull the remote image when referencePolicy is Local?
>>>>
>>>
>>>
>>> Is pullthrough enabled on your registry?
>>> https://docs.openshift.org/latest/install_config/registry/ex
>>> tended_registry_configuration.html#middleware-repository-pullthrough
>>>
>>> also:
>>> "When performing pullthrough, the registry will use pull credentials
>>> found in the project associated with the image stream tag that is being
>>> referenced. "
>>>
>>> So if your imagestream is in a different project, you need to make sure
>>> the credentials are in the right place.
>>>
>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>> Ben Parees | OpenShift
>>>
>>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-16 Thread Lionel Orellana
>
> Is pullthrough enabled on your registry?


Yes.

"When performing pullthrough, the registry will use pull credentials found
> in the project associated with the image stream tag that is being
> referenced"
>


I'm deploying in the same project where the image stream is. I have
a dockercfg secret in the project with credentials for the remote registry.
I linked that secret to the deployment as pull secret. It works when
remotePolicy is Source so I know the credentials are Ok. But how does the
registry find the pull credentials to use? I assume it looks for the server
name in the dockercfg secret?


On 17 November 2017 at 10:01, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Thu, Nov 16, 2017 at 5:36 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I imported a remote image and set  referencePolicy.type to Local in the
>> resulting tag. When I try to deploy an pod using this image stream tag I
>> get "rpc error: code = 2 desc = manifest unknown: manifest unknown".
>>
>> If I change the referencePolicy type to Source then the pod pulls the
>> image fine from the remote registry. But this requires linking a pull
>> secret to the deployment which is an extra step I could do without. I
>> thought I would get around that by referencing the Local image.
>>
>> How do I pull the remote image when referencePolicy is Local?
>>
>
>
> Is pullthrough enabled on your registry?
> https://docs.openshift.org/latest/install_config/
> registry/extended_registry_configuration.html#middleware-
> repository-pullthrough
>
> also:
> "When performing pullthrough, the registry will use pull credentials found
> in the project associated with the image stream tag that is being
> referenced. "
>
> So if your imagestream is in a different project, you need to make sure
> the credentials are in the right place.
>
>
>> Thanks
>>
>>
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Remote image with referencePolicy.type=Local -> manifest unknown

2017-11-16 Thread Lionel Orellana
Hi,

I imported a remote image and set  referencePolicy.type to Local in the
resulting tag. When I try to deploy an pod using this image stream tag I
get "rpc error: code = 2 desc = manifest unknown: manifest unknown".

If I change the referencePolicy type to Source then the pod pulls the image
fine from the remote registry. But this requires linking a pull secret to
the deployment which is an extra step I could do without. I thought I would
get around that by referencing the Local image.

How do I pull the remote image when referencePolicy is Local?

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


Force external image sync

2017-11-16 Thread Lionel Orellana
Hi,

I imported an image from an external private registry and set
*importPolicy.scheduled *on the resulting image stream tag to true. It
works nicely but it can take quite a few minutes for changes on the
external tag to be sync'ed back.

Is there an oc command to force the sync?

Thanks

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


Re: OCP: Failed to push image: unauthorized: authentication req, uired

2017-10-26 Thread Lionel Orellana
Ah I think when I first installed the Origin cluster there were all these
problems with the registry ip and the proxy so I created the registry form
a yml file (to keep the ip consistent) and that yml file didn't set the
proxy vars. These problems are gone now that the default registry is set to
the service name instead of the ip. But it does mean proxy vars are added
to the registry deployment.

On 27 October 2017 at 07:45, Lionel Orellana <lione...@gmail.com> wrote:

> I have an Origin 3.6 cluster and the proxy vars are not set in the
> registry pod at all.
>
> -bash-4.2$ oc rsh docker-registry-9-c9mgd env | grep PROXY
>
> -bash-4.2$
>
> Whereas in the OCP 3.6 cluster they are.
>
> -bash-4.2$ oc rsh docker-registry-1-9z8p2 env | grep PROXY
> NO_PROXY=.x,.cluster.local,.svc,172.19.10.100,172.
> 19.10.202,172.19.10.203
> HTTP_PROXY=http://x
> HTTPS_PROXY=http://xxx
>
> Instead of adding the api server address to NO_PROXY I might as well
> remove all the proxy vars ? Why would the registry need a proxy anyway?
>
> On 26 October 2017 at 22:55, Ben Parees <bpar...@redhat.com> wrote:
>
>>
>>
>> On Thu, Oct 26, 2017 at 12:43 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> This works.Would have thought the api server address was added
>>> automatically to NO_PROXY?
>>>
>>
>> it's supposed to be, but i do think there is a bug open where people have
>> seen it not be added:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1504464
>>
>>
>>
>>>
>>> -bash-4.2$ oc rsh docker-registry-1-9z8p2
>>> sh-4.2$ export NO_PROXY=$NO_PROXY,172.23.192.1
>>> sh-4.2$ oc whoami
>>> system:serviceaccount:default:registry
>>> sh-4.2$
>>>
>>> On 26 October 2017 at 20:54, Ben Parees <bpar...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 26, 2017 at 11:50 AM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>> I didn't put it there.
>>>>>
>>>>> I another cluster this works.
>>>>>
>>>>> -bash-4.2$ oc rsh docker-registry-9-c9mgd oc whoami
>>>>> system:serviceaccount:default:registry
>>>>>
>>>>> -bash-4.2$ oc rsh docker-registry-9-c9mgd which oc
>>>>> /usr/bin/oc
>>>>>
>>>>>
>>>> ok, it looks like it was removed on 3.7.
>>>>
>>>> Anyway you've certainly established there is a networking issue between
>>>> your registry pod and the api server in your cluster
>>>> (but oddly not between other pods an the api server)  Adding the
>>>> networking team to the thread.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> On 26 October 2017 at 20:37, Ben Parees <bpar...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 26, 2017 at 10:53 AM, Lionel Orellana <lione...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Interestingly
>>>>>>>
>>>>>>> -bash-4.2$ oc rsh router-1-bf95x oc whoami
>>>>>>> system:serviceaccount:default:router
>>>>>>> -bash-4.2$ oc rsh docker-registry-1-9z8p2 oc whoami
>>>>>>> Unable to connect to the server: Service Unavailable
>>>>>>> command terminated with exit code 1
>>>>>>>
>>>>>>
>>>>>> the registry image doesn't even contain an oc client binary (unless
>>>>>> you put one there?) so i'm not sure what that is doing.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 26 October 2017 at 19:50, Lionel Orellana <lione...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Well this works from one of the hosts (using a token from oc whoami)
>>>>>>>>
>>>>>>>> curl -X GET -H "Authorization: Bearer $TOKEN"
>>>>>>>> https://172.23.192.1/oapi/v1/users/~
>>>>>>>>
>>>>>>>> In the error msg
>>>>>>>>
>>>>>>>> msg="*invalid token*: Get https://172.23.192.1:443/oapi/v1/users/~
>>>>>>>> <https://172.23.192.1/oapi/v1/users/~>: Service Unavailable"
>>>>>>>>
>>>>>>&

Re: OCP: Failed to push image: unauthorized: authentication req, uired

2017-10-26 Thread Lionel Orellana
I have an Origin 3.6 cluster and the proxy vars are not set in the registry
pod at all.

-bash-4.2$ oc rsh docker-registry-9-c9mgd env | grep PROXY
-bash-4.2$

Whereas in the OCP 3.6 cluster they are.

-bash-4.2$ oc rsh docker-registry-1-9z8p2 env | grep PROXY
NO_PROXY=.x,.cluster.local,.svc,172.19.10.100,172.19.10.202,172.19.10.203
HTTP_PROXY=http://x
HTTPS_PROXY=http://xxx

Instead of adding the api server address to NO_PROXY I might as well remove
all the proxy vars ? Why would the registry need a proxy anyway?

On 26 October 2017 at 22:55, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Thu, Oct 26, 2017 at 12:43 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> This works.Would have thought the api server address was added
>> automatically to NO_PROXY?
>>
>
> it's supposed to be, but i do think there is a bug open where people have
> seen it not be added:
> https://bugzilla.redhat.com/show_bug.cgi?id=1504464
>
>
>
>>
>> -bash-4.2$ oc rsh docker-registry-1-9z8p2
>> sh-4.2$ export NO_PROXY=$NO_PROXY,172.23.192.1
>> sh-4.2$ oc whoami
>> system:serviceaccount:default:registry
>> sh-4.2$
>>
>> On 26 October 2017 at 20:54, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 26, 2017 at 11:50 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> I didn't put it there.
>>>>
>>>> I another cluster this works.
>>>>
>>>> -bash-4.2$ oc rsh docker-registry-9-c9mgd oc whoami
>>>> system:serviceaccount:default:registry
>>>>
>>>> -bash-4.2$ oc rsh docker-registry-9-c9mgd which oc
>>>> /usr/bin/oc
>>>>
>>>>
>>> ok, it looks like it was removed on 3.7.
>>>
>>> Anyway you've certainly established there is a networking issue between
>>> your registry pod and the api server in your cluster
>>> (but oddly not between other pods an the api server)  Adding the
>>> networking team to the thread.
>>>
>>>
>>>
>>>
>>>>
>>>> On 26 October 2017 at 20:37, Ben Parees <bpar...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 26, 2017 at 10:53 AM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Interestingly
>>>>>>
>>>>>> -bash-4.2$ oc rsh router-1-bf95x oc whoami
>>>>>> system:serviceaccount:default:router
>>>>>> -bash-4.2$ oc rsh docker-registry-1-9z8p2 oc whoami
>>>>>> Unable to connect to the server: Service Unavailable
>>>>>> command terminated with exit code 1
>>>>>>
>>>>>
>>>>> the registry image doesn't even contain an oc client binary (unless
>>>>> you put one there?) so i'm not sure what that is doing.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On 26 October 2017 at 19:50, Lionel Orellana <lione...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Well this works from one of the hosts (using a token from oc whoami)
>>>>>>>
>>>>>>> curl -X GET -H "Authorization: Bearer $TOKEN"
>>>>>>> https://172.23.192.1/oapi/v1/users/~
>>>>>>>
>>>>>>> In the error msg
>>>>>>>
>>>>>>> msg="*invalid token*: Get https://172.23.192.1:443/oapi/v1/users/~
>>>>>>> <https://172.23.192.1/oapi/v1/users/~>: Service Unavailable"
>>>>>>>
>>>>>>> I wonder if the invalid toke part is the issue.
>>>>>>>
>>>>>>> On 26 October 2017 at 19:16, Ben Parees <bpar...@redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 26, 2017 at 8:11 AM, Lionel Orellana <
>>>>>>>> lione...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In a new OCP 3.6 installation I'm trying to deploy JBoss EAP 7.0
>>>>>>>>> from the catalog.
>>>>>>>>>
>>>>>>>>> This is in a project for which I am the admin.
>>>>>>>>>
>>>>>>>>> It's failing to push 

Re: OCP: Failed to push image: unauthorized: authentication req, uired

2017-10-26 Thread Lionel Orellana
This works.Would have thought the api server address was added
automatically to NO_PROXY?

-bash-4.2$ oc rsh docker-registry-1-9z8p2
sh-4.2$ export NO_PROXY=$NO_PROXY,172.23.192.1
sh-4.2$ oc whoami
system:serviceaccount:default:registry
sh-4.2$

On 26 October 2017 at 20:54, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Thu, Oct 26, 2017 at 11:50 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> I didn't put it there.
>>
>> I another cluster this works.
>>
>> -bash-4.2$ oc rsh docker-registry-9-c9mgd oc whoami
>> system:serviceaccount:default:registry
>>
>> -bash-4.2$ oc rsh docker-registry-9-c9mgd which oc
>> /usr/bin/oc
>>
>>
> ok, it looks like it was removed on 3.7.
>
> Anyway you've certainly established there is a networking issue between
> your registry pod and the api server in your cluster
> (but oddly not between other pods an the api server)  Adding the
> networking team to the thread.
>
>
>
>
>>
>> On 26 October 2017 at 20:37, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 26, 2017 at 10:53 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Interestingly
>>>>
>>>> -bash-4.2$ oc rsh router-1-bf95x oc whoami
>>>> system:serviceaccount:default:router
>>>> -bash-4.2$ oc rsh docker-registry-1-9z8p2 oc whoami
>>>> Unable to connect to the server: Service Unavailable
>>>> command terminated with exit code 1
>>>>
>>>
>>> the registry image doesn't even contain an oc client binary (unless you
>>> put one there?) so i'm not sure what that is doing.
>>>
>>>
>>>
>>>>
>>>> On 26 October 2017 at 19:50, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>> Well this works from one of the hosts (using a token from oc whoami)
>>>>>
>>>>> curl -X GET -H "Authorization: Bearer $TOKEN"
>>>>> https://172.23.192.1/oapi/v1/users/~
>>>>>
>>>>> In the error msg
>>>>>
>>>>> msg="*invalid token*: Get https://172.23.192.1:443/oapi/v1/users/~
>>>>> <https://172.23.192.1/oapi/v1/users/~>: Service Unavailable"
>>>>>
>>>>> I wonder if the invalid toke part is the issue.
>>>>>
>>>>> On 26 October 2017 at 19:16, Ben Parees <bpar...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 26, 2017 at 8:11 AM, Lionel Orellana <lione...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> In a new OCP 3.6 installation I'm trying to deploy JBoss EAP 7.0
>>>>>>> from the catalog.
>>>>>>>
>>>>>>> This is in a project for which I am the admin.
>>>>>>>
>>>>>>> It's failing to push the image to the registry
>>>>>>>
>>>>>>> Pushing image docker-registry.default.svc:5000/bimorl/jboss-eap70:latest
>>>>>>> ...
>>>>>>> Registry server Address:
>>>>>>> Registry server User Name: serviceaccount
>>>>>>> Registry server Email: serviceacco...@example.org
>>>>>>> Registry server Password: <>
>>>>>>> error: build error: Failed to push image: unauthorized:
>>>>>>> authentication required
>>>>>>>
>>>>>>
>>>>>>> In the registry logs I see
>>>>>>>
>>>>>>> 172.23.140.1 - - [26/Oct/2017:05:08:19 +] "GET
>>>>>>> /openshift/token?account=serviceaccount=repository%3Ab
>>>>>>> imorl%2Fjboss-eap70%3Apush%2Cpull HTTP/1.1" 401 0 "" "docker/1.12.6
>>>>>>> go/go1.8.3 kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64
>>>>>>> UpstreamClient(go-dockerclient)"
>>>>>>> time="2017-10-26T05:08:19.116844289Z" level=debug msg="invalid
>>>>>>> token: Get https://172.23.192.1:443/oapi/v1/users/~: *Service
>>>>>>> Unavailable*" go.version=go1.7.6 
>>>>>>> http.request.host="docker-registry.default.svc:5000"
>>>>>>> http.request.id=467674a1-8618-4986-9e7f-b92a06afa43d
>>>>>>> http.request.method=GET http.request.remoteaddr="172.23.140.1:38284"
>>>>>>> http.request.uri="/openshift/token?account=serviceaccount
>>>>>>> ope=repository%3Abimorl%2Fjboss-eap70%3Apush%2Cpull"
>>>>>>> http.request.useragent="docker/1.12.6 go/go1.8.3
>>>>>>> kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64
>>>>>>> UpstreamClient(go-dockerclient)" 
>>>>>>> instance.id=e5e8a55e-c3bc-4dfa-a706-e844ddbbdf44
>>>>>>> openshift.logger=registry
>>>>>>>
>>>>>>
>>>>>> sounds like your registry is unable to reach your api server.  I
>>>>>> would check if other pods running within your cluster are able to access
>>>>>> the api server (ie run oc client commands from within a pod, against the
>>>>>> kubernetes service ip)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> users mailing list
>>>>>>> users@lists.openshift.redhat.com
>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ben Parees | OpenShift
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ben Parees | OpenShift
>>>
>>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: OCP: Failed to push image: unauthorized: authentication req, uired

2017-10-26 Thread Lionel Orellana
Well this works from one of the hosts (using a token from oc whoami)

curl -X GET -H "Authorization: Bearer $TOKEN"
https://172.23.192.1/oapi/v1/users/~

In the error msg

msg="*invalid token*: Get https://172.23.192.1:443/oapi/v1/users/~
<https://172.23.192.1/oapi/v1/users/~>: Service Unavailable"

I wonder if the invalid toke part is the issue.

On 26 October 2017 at 19:16, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Thu, Oct 26, 2017 at 8:11 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hi,
>>
>> In a new OCP 3.6 installation I'm trying to deploy JBoss EAP 7.0 from the
>> catalog.
>>
>> This is in a project for which I am the admin.
>>
>> It's failing to push the image to the registry
>>
>> Pushing image docker-registry.default.svc:5000/bimorl/jboss-eap70:latest
>> ...
>> Registry server Address:
>> Registry server User Name: serviceaccount
>> Registry server Email: serviceacco...@example.org
>> Registry server Password: <>
>> error: build error: Failed to push image: unauthorized: authentication
>> required
>>
>
>> In the registry logs I see
>>
>> 172.23.140.1 - - [26/Oct/2017:05:08:19 +] "GET
>> /openshift/token?account=serviceaccount=repository%
>> 3Abimorl%2Fjboss-eap70%3Apush%2Cpull HTTP/1.1" 401 0 "" "docker/1.12.6
>> go/go1.8.3 kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64
>> UpstreamClient(go-dockerclient)"
>> time="2017-10-26T05:08:19.116844289Z" level=debug msg="invalid token:
>> Get https://172.23.192.1:443/oapi/v1/users/~: *Service Unavailable*"
>> go.version=go1.7.6 http.request.host="docker-registry.default.svc:5000"
>> http.request.id=467674a1-8618-4986-9e7f-b92a06afa43d
>> http.request.method=GET http.request.remoteaddr="172.23.140.1:38284"
>> http.request.uri="/openshift/token?account=serviceaccount
>> ope=repository%3Abimorl%2Fjboss-eap70%3Apush%2Cpull"
>> http.request.useragent="docker/1.12.6 go/go1.8.3
>> kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64
>> UpstreamClient(go-dockerclient)" 
>> instance.id=e5e8a55e-c3bc-4dfa-a706-e844ddbbdf44
>> openshift.logger=registry
>>
>
> sounds like your registry is unable to reach your api server.  I would
> check if other pods running within your cluster are able to access the api
> server (ie run oc client commands from within a pod, against the kubernetes
> service ip)
>
>
>
>>
>> Any ideas?
>>
>> Thanks
>>
>>
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: OCP: Failed to push image: unauthorized: authentication req, uired

2017-10-26 Thread Lionel Orellana
I've seen the issue
<https://github.com/openshift/origin/issues/4518#issuecomment-140460107>where
this error happens on the first build attempt. However I'm getting the
error on subsequent builds.

This is the first cluster I configure with the openshift-ovs-multitenant
plugin. Could that be interfering?

On 26 October 2017 at 17:11, Lionel Orellana <lione...@gmail.com> wrote:

> Hi,
>
> In a new OCP 3.6 installation I'm trying to deploy JBoss EAP 7.0 from the
> catalog.
>
> This is in a project for which I am the admin.
>
> It's failing to push the image to the registry
>
> Pushing image docker-registry.default.svc:5000/bimorl/jboss-eap70:latest
> ...
> Registry server Address:
> Registry server User Name: serviceaccount
> Registry server Email: serviceacco...@example.org
> Registry server Password: <>
> error: build error: Failed to push image: unauthorized: authentication
> required
>
> In the registry logs I see
>
> 172.23.140.1 - - [26/Oct/2017:05:08:19 +] "GET
> /openshift/token?account=serviceaccount=repository%3Abimorl%2Fjboss-eap70%3Apush%2Cpull
> HTTP/1.1" 401 0 "" "docker/1.12.6 go/go1.8.3 kernel/3.10.0-693.2.2.el7.x86_64
> os/linux arch/amd64 UpstreamClient(go-dockerclient)"
> time="2017-10-26T05:08:19.116844289Z" level=debug msg="invalid token: Get
> https://172.23.192.1:443/oapi/v1/users/~: *Service Unavailable*"
> go.version=go1.7.6 http.request.host="docker-registry.default.svc:5000"
> http.request.id=467674a1-8618-4986-9e7f-b92a06afa43d
> http.request.method=GET http.request.remoteaddr="172.23.140.1:38284"
> http.request.uri="/openshift/token?account=serviceaccount&
> scope=repository%3Abimorl%2Fjboss-eap70%3Apush%2Cpull"
> http.request.useragent="docker/1.12.6 go/go1.8.3
> kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64 
> UpstreamClient(go-dockerclient)"
> instance.id=e5e8a55e-c3bc-4dfa-a706-e844ddbbdf44 openshift.logger=registry
>
> Any ideas?
>
> Thanks
>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


OCP: Failed to push image: unauthorized: authentication req,uired

2017-10-26 Thread Lionel Orellana
Hi,

In a new OCP 3.6 installation I'm trying to deploy JBoss EAP 7.0 from the
catalog.

This is in a project for which I am the admin.

It's failing to push the image to the registry

Pushing image docker-registry.default.svc:5000/bimorl/jboss-eap70:latest ...
Registry server Address:
Registry server User Name: serviceaccount
Registry server Email: serviceacco...@example.org
Registry server Password: <>
error: build error: Failed to push image: unauthorized: authentication
required

In the registry logs I see

172.23.140.1 - - [26/Oct/2017:05:08:19 +] "GET
/openshift/token?account=serviceaccount=repository%3Abimorl%2Fjboss-eap70%3Apush%2Cpull
HTTP/1.1" 401 0 "" "docker/1.12.6 go/go1.8.3
kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64
UpstreamClient(go-dockerclient)"
time="2017-10-26T05:08:19.116844289Z" level=debug msg="invalid token: Get
https://172.23.192.1:443/oapi/v1/users/~: *Service Unavailable*"
go.version=go1.7.6 http.request.host="docker-registry.default.svc:5000"
http.request.id=467674a1-8618-4986-9e7f-b92a06afa43d
http.request.method=GET http.request.remoteaddr="172.23.140.1:38284"
http.request.uri="/openshift/token?account=serviceaccount=repository%3Abimorl%2Fjboss-eap70%3Apush%2Cpull"
http.request.useragent="docker/1.12.6 go/go1.8.3
kernel/3.10.0-693.2.2.el7.x86_64 os/linux arch/amd64
UpstreamClient(go-dockerclient)"
instance.id=e5e8a55e-c3bc-4dfa-a706-e844ddbbdf44
openshift.logger=registry

Any ideas?

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


Re: LDAP bindPassword in Ansible inventory

2017-10-24 Thread Lionel Orellana
Good idea Joel.

In the inventory file I can use

'bindPassword': '{{ ldap_bind_password }}'

and pass *-e ldap_bind_password=x* when running the playbook.

Ansible vault is probably the way to go but this will do for now.

Thanks!


On 24 October 2017 at 17:19, Joel Pearson <japear...@agiledigital.com.au>
wrote:

> Maybe if you use a vars yaml file, it might work? I was going to try it
> today, but I didn't get around to it, was hoping you'd get it working first?
>
> By a vars file I mean
>
> ansible-playbook -e "@varsfile.yml"
>
> With something like this in there, but obviously the encrypted bit
>
> openshift_master_identity_providers:
> - name: active_directory
>   challenge: 'true'
>   login: 'true'
>   kind: LDAPPasswordIdentityProvider
>   attributes:
> email:
> - mail
> id:
> - sAMAccountName
> name:
> - displayName
> preferredUsername:
> - sAMAccountName
>   insecure: 'true'
>   bindDN: 'CN=,OU=Azure Users,OU=DEH-Staff,DC=internal,DC=govt'
>   bindPassword: ''
>   url: ldap://ad-lb.envris-os-dev.agiledigital.com.au:389/ou=
> deh-staff,dc=internal,dc=govt?samAccountName
>
>
> On Tue, Oct 24, 2017 at 4:59 PM Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Well adding this to the inventory file doesn't work (even if the files
>> are copied to masters before hand).
>>
>> 'bindPassword': {'file': '/root/bindPassword.encrypted', 'keyFile':
>> '/root/bindPassword.key'},
>>
>> Is there any way to encrypt the bindPassword in the inventory file?
>>
>> On 21 October 2017 at 11:43, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> Looking at the master role it just copies the configuration from the
>>> inventory to the config file so I do have to copy the encryption files
>>> beforehand. Will have to try if the format in the inventory file is right.
>>> On Sat, 21 Oct 2017 at 9:15 am, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I see there's a way to encrypt
>>>> <https://docs.openshift.org/latest/install_config/master_node_configuration.html#master-node-configuration-passwords-and-other-data>an
>>>> ldap bind password for use in the master configs.
>>>>
>>>> But I'm not sure how this would work in the Ansible inventory
>>>> configuration for the identity provider.
>>>>
>>>> If I use an Encrypted External File do I need to copy the file to all
>>>> the masters first? Or is the playbook going to copy it from the ansible
>>>> host?
>>>>
>>>> What should the openshift_master_identity_providers look like?
>>>>
>>>> openshift_master_identity_providers=[{'name': 'my_ldap_provider', ...,
>>>> 'kind': 'LDAPPasswordIdentityProvider', ..., *'bindPassword': {
>>>> 'file': 'bindPassword.encrypted'*
>>>> *'keyFile': 'bindPassword.key'}*, ...}]
>>>>
>>>> Thanks
>>>>
>>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
> --
> Kind Regards,
>
> Joel Pearson
> Agile Digital | Senior Software Consultant
>
> Love Your Software™ | ABN 98 106 361 273
> p: 1300 858 277 | m: 0405 417 843 <0405417843> | w: agiledigital.com.au
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: LDAP bindPassword in Ansible inventory

2017-10-23 Thread Lionel Orellana
Well adding this to the inventory file doesn't work (even if the files are
copied to masters before hand).

'bindPassword': {'file': '/root/bindPassword.encrypted', 'keyFile':
'/root/bindPassword.key'},

Is there any way to encrypt the bindPassword in the inventory file?

On 21 October 2017 at 11:43, Lionel Orellana <lione...@gmail.com> wrote:

> Looking at the master role it just copies the configuration from the
> inventory to the config file so I do have to copy the encryption files
> beforehand. Will have to try if the format in the inventory file is right.
> On Sat, 21 Oct 2017 at 9:15 am, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I see there's a way to encrypt
>> <https://docs.openshift.org/latest/install_config/master_node_configuration.html#master-node-configuration-passwords-and-other-data>an
>> ldap bind password for use in the master configs.
>>
>> But I'm not sure how this would work in the Ansible inventory
>> configuration for the identity provider.
>>
>> If I use an Encrypted External File do I need to copy the file to all the
>> masters first? Or is the playbook going to copy it from the ansible host?
>>
>> What should the openshift_master_identity_providers look like?
>>
>> openshift_master_identity_providers=[{'name': 'my_ldap_provider', ...,
>> 'kind': 'LDAPPasswordIdentityProvider', ..., *'bindPassword': { 'file':
>> 'bindPassword.encrypted'*
>> *'keyFile': 'bindPassword.key'}*, ...}]
>>
>> Thanks
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Containerized OCP requires atomic-openshift?

2017-10-21 Thread Lionel Orellana
The set_version_rpm task in the openshift_version role has the check for
the atomic-openshift package. This is fine and is being skipped in my
containerised installation. But the same check was added to the main task
of the role as part of the 3.6 release (it's not there in the 1.5 branch).
Looks something like this

*openshift-ansible/playbooks/byo/roles/openshift_version/tasks/mail.yml*

block:
  - name: Set openshift_version for rpm installation
include: set_version_rpm.yml *<--- this does the check but it's skipped
for containerized, makes sense*
when: not is_containerized | bool

  - name: Set openshift_version for containerized installation
include: set_version_containerized.yml
when: is_containerized | bool

  - block:
- name: Get available {{ openshift.common.service_type}} version *<--
same check as set_version_rpm.yml, why here?*
  repoquery:
name: "{{ openshift.common.service_type}}"
ignore_excluders: true
  register: rpm_results
- fail:
msg: "Package {{ openshift.common.service_type}} not found"
  when: not rpm_results.results.package_found
...
when: *<-- why do we need the rpm package for a containerized install
on non atomic hosts (e.g. RHEL)?*
- is_containerized | bool
- not is_atomic | bool

On 21 October 2017 at 21:59, Lionel Orellana <lione...@gmail.com> wrote:

> Thanks Chris.
>
> I have those 3 properties (although it looks like deployment_type is now
> openshift_deployment_type? either way it's not working).
>
> Fair enough if it wants to install the excluders but why the
> atomic-openshift package?
>
>
>
> On 21 October 2017 at 21:48, Chris Ganderton <ch...@thefraggle.com> wrote:
>
>> >
>> > From: users-boun...@lists.openshift.redhat.com <
>> users-boun...@lists.openshift.redhat.com> on behalf of Lionel Orellana <
>> lione...@gmail.com>
>> > Sent: Saturday, October 21, 2017 11:14 AM
>> > To: users
>> > Subject: Containerized OCP requires atomic-openshift?
>> >
>> > Hi,
>> >
>> > I'm trying to install OCP 3.6. I've done a few installations of Origin
>> before but it's my first OCP.
>> >
>> > I'm installing on RHEL and have set containerized=true in the inventory.
>> >
>> > The byo playbook for some reason insists on requiring atomic-openshift
>> to be installed.
>> >
>> > Failure summary:
>> >
>> >   1. Hosts:
>> >  Play: Determine openshift_version to configure on first master
>> >  Task: openshift_version : fail
>> >  Message:  Package atomic-openshift not found
>> >
>>
>> Hi Lionel,
>>
>>
>> The playbook will still try to install the RPM packages for
>> docker-excluder and openshfit-excluder, even in a containerized
>> deployment.
>>
>>
>> Something that's tripped me up before as well, is having the correct
>> values for the below variables in the ansible inventory:
>>
>>
>> openshift_release=v3.6
>>
>> deployment_type=openshift-enterprise
>> containerized=True
>>
>> -Chris
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Containerized OCP requires atomic-openshift?

2017-10-21 Thread Lionel Orellana
Thanks Chris.

I have those 3 properties (although it looks like deployment_type is now
openshift_deployment_type? either way it's not working).

Fair enough if it wants to install the excluders but why the
atomic-openshift package?



On 21 October 2017 at 21:48, Chris Ganderton <ch...@thefraggle.com> wrote:

> >
> > From: users-boun...@lists.openshift.redhat.com <users-bounces@lists.
> openshift.redhat.com> on behalf of Lionel Orellana <lione...@gmail.com>
> > Sent: Saturday, October 21, 2017 11:14 AM
> > To: users
> > Subject: Containerized OCP requires atomic-openshift?
> >
> > Hi,
> >
> > I'm trying to install OCP 3.6. I've done a few installations of Origin
> before but it's my first OCP.
> >
> > I'm installing on RHEL and have set containerized=true in the inventory.
> >
> > The byo playbook for some reason insists on requiring atomic-openshift
> to be installed.
> >
> > Failure summary:
> >
> >   1. Hosts:
> >  Play: Determine openshift_version to configure on first master
> >  Task: openshift_version : fail
> >  Message:  Package atomic-openshift not found
> >
>
> Hi Lionel,
>
>
> The playbook will still try to install the RPM packages for
> docker-excluder and openshfit-excluder, even in a containerized
> deployment.
>
>
> Something that's tripped me up before as well, is having the correct
> values for the below variables in the ansible inventory:
>
>
> openshift_release=v3.6
>
> deployment_type=openshift-enterprise
> containerized=True
>
> -Chris
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Containerized OCP requires atomic-openshift?

2017-10-21 Thread Lionel Orellana
Hi,

I'm trying to install OCP 3.6. I've done a few installations of Origin
before but it's my first OCP.

I'm installing on RHEL and have set containerized=true in the inventory.

The byo playbook for some reason insists on requiring atomic-openshift to
be installed.

Failure summary:

  1. Hosts:
 Play: Determine openshift_version to configure on first master
 Task: openshift_version : fail
 Message:  Package atomic-openshift not found

I tried removing openshift_image_tag but same result. Why is it looking for
this rpm package for a containerized installation?

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


LDAP bindPassword in Ansible inventory

2017-10-20 Thread Lionel Orellana
Hi,

I see there's a way to encrypt
an
ldap bind password for use in the master configs.

But I'm not sure how this would work in the Ansible inventory configuration
for the identity provider.

If I use an Encrypted External File do I need to copy the file to all the
masters first? Or is the playbook going to copy it from the ansible host?

What should the openshift_master_identity_providers look like?

openshift_master_identity_providers=[{'name': 'my_ldap_provider', ...,
'kind': 'LDAPPasswordIdentityProvider', ..., *'bindPassword': { 'file':
'bindPassword.encrypted'*
*'keyFile': 'bindPassword.key'}*, ...}]

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


2 clusters with the same internal ip addresses

2017-10-16 Thread Lionel Orellana
Hi,


Can two different clusters use the same ip ranges for
osm_cluster_network_cidr and  openshift_portal_net? Those ip’s are all
internal so should be ok? I'm trying to save the hassle of reserving two
more ranges for my second cluster. I don't want/need them to know about
each other.


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


Upgrading Grafana

2017-09-17 Thread Lionel Orellana
Hi,

I've done 2 upgrades to the metrics system and noticed that Grafana doesn't
get updated.

During the initial installation the Grafana image was pushed to the
Openshift registry as an image stream. Do I have to manually push it again?
Shouldn't this be part of the metrics playbook?

Thanks

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


Re: 1.5 Metrics upgrade did nothing to origin-metrics-cassandra

2017-09-17 Thread Lionel Orellana
For reference I believe the issue was the presence of Ansible @retry files.
The metrics playbook simply stopped after one master and didn't complete
the upgrade. I removed the retry files and cassandra was updated correctly.

On 23 August 2017 at 21:05, Lionel Orellana <lione...@gmail.com> wrote:

> Hello
>
> As the last step in upgrading my cluster from 1.4. to 1.5 I ran the
> metrics playbook.
>
> It upgraded origin-metrics-hawkular-metrics and origin-metrics-heapster
> to 1.5.1 but not  origin-metrics-cassandra which is still showing 1.4.1.
> There is a tag in docker hub for it so I was expecting it to be used.
>
> Is this a bug in the playbook? Can I/should I change the cassandra rc to
> use 1.5.1?
> I am planning on upgrading to 3.6 next so maybe that will take care of it?
>
> Thanks
>
> Lionel
>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Origin to OCP

2017-08-24 Thread Lionel Orellana
I'm actually running Origin on RHEL7. That's why it was tempting to just
flick the deployment type. But yeh the service names won't match and it'll
end up in a mess.  Thanks.

On 24 August 2017 at 11:59, Nakayama Kenjiro <nakayamakenj...@gmail.com>
wrote:

> I guess that you are using Origin on CentOS or Fedora.
> When you use OCP, you need to register subscription manager on RHEL7
> and it is only available with RHEL 7. So, you are supposed to have to
> start installing RHEL7 and deploy OCP cluster.
>
> If you are using Origin on RHEL7, I agree with Clayton's comment, but
> I believe that most Origin users are running on CentOS/Fedora.
>
>
> On Thu, Aug 24, 2017 at 6:23 AM, Clayton Coleman <ccole...@redhat.com>
> wrote:
>
>> I suspect that changing deployment type will hit issues on upgrade.
>> In particular, systemd service names may change on nodes and masters
>> and not get cleaned up.  I'm not sure what other subtle issues would
>> be hit.
>>
>> > On Aug 23, 2017, at 4:26 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>> >
>> > I have an Origin 1.5 cluster. We now bought licenses for OCP. It is
>> tempting to simply change the deployment type in the inventory file and
>> upgrade to 3.6. Sounds like a bad idea. Is it?
>> >
>> > Cheers
>> >
>> > Lionel.
>> > ___
>> > users mailing list
>> > users@lists.openshift.redhat.com
>> > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>
>
>
> --
> Kenjiro NAKAYAMA <nakayamakenj...@gmail.com>
> GPG Key fingerprint = ED8F 049D E67A 727D 9A44  8E25 F44B E208 C946 5EB9
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Origin to OCP

2017-08-23 Thread Lionel Orellana
I have an Origin 1.5 cluster. We now bought licenses for OCP. It is
tempting to simply change the deployment type in the inventory file and
upgrade to 3.6. Sounds like a bad idea. Is it?

Cheers

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


1.5 Metrics upgrade did nothing to origin-metrics-cassandra

2017-08-23 Thread Lionel Orellana
Hello

As the last step in upgrading my cluster from 1.4. to 1.5 I ran the metrics
playbook.

It upgraded origin-metrics-hawkular-metrics and origin-metrics-heapster to
1.5.1 but not  origin-metrics-cassandra which is still showing 1.4.1. There
is a tag in docker hub for it so I was expecting it to be used.

Is this a bug in the playbook? Can I/should I change the cassandra rc to
use 1.5.1?
I am planning on upgrading to 3.6 next so maybe that will take care of it?

Thanks

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


Re: Kubernetes Jenkins slaves in parallel

2017-02-20 Thread Lionel Orellana
Thanks Ben. Here's the JIRA:
https://issues.jenkins-ci.org/browse/JENKINS-42184




On 19 February 2017 at 10:43, Ben Parees <bpar...@redhat.com> wrote:

> This sounds like great feedback to get into the kubernetes plugin
> documentation via PR:
> https://github.com/jenkinsci/kubernetes-plugin/
>
> or open an issue against the plugin for it here:
> https://issues.jenkins-ci.org/secure/Dashboard.jspa
>
>
> On Sat, Feb 18, 2017 at 6:38 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> After much head-banging over this I finally got pods created in parallel.
>>
>>
>>1. Creating multiple podTemplates using different labels for each
>>allows you to create the pods in parallel (it also allows concurrent jobs
>>which are otherwise serialised too). But the plugin treats all 
>> podTemplates
>>in a Run as nested templates even when they are not. Every podTemplate in
>>the pipeline effectively inherits from previously declared templates.
>>
>>2. The hacky workaround to stop this is to clear all previously
>>stacked template names from the Run before creating a new template. Call
>>this function before any occurrence of podTemplate:
>>
>> @NonCPS
>> def clearTemplateNames() {
>> def r = script.currentBuild.rawBuild
>> def action = r.getAction(PodTemplateAction.class);
>> if(action) {
>> action.names.clear()
>> }
>> }
>>
>>
>> With this I can parallelise pods to my hearts content.
>>
>> Cheers
>>
>> Lionel.
>>
>> On 7 February 2017 at 00:06, Ben Parees <bpar...@redhat.com> wrote:
>>
>>> I'm trying to understand if this is a general jenkins pipeline issue or
>>> a problem specifically w/ the kubernetes plugin.
>>>
>>> Given that it seems to run properly (in parallel) when the two parallel
>>> steps are not dependent on launching distinct slaves, it sounds like a
>>> problem in the kubernetes plugin itself(this is the component responsible
>>> for launching slave pods on your cluster)  I would start by opening an
>>> issue in that repo:
>>>
>>> https://github.com/jenkinsci/kubernetes-plugin/
>>> or a JIRA:
>>> https://issues.jenkins-ci.org/browse/JENKINS-38260?jql=text%
>>> 20~%20%22kubernetes-plugin%22
>>>
>>>
>>> On Sun, Feb 5, 2017 at 6:56 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> The intended usage might be to create a pod with all the containers
>>>> you'll need during in the pipeline.
>>>>
>>>> Defining the same container twice to run them in parallel works.
>>>>
>>>> podTemplate(name: 'jenkins-slave', label: 'kube-node',  instanceCap: 4,
>>>> containers: [
>>>> containerTemplate(
>>>> name: 'maven1',
>>>> image: "${registry}:5000/jenkins/slave-maven",
>>>> command: '/bin/bash',
>>>> args: '',
>>>> alwaysPullImage: true,
>>>> ttyEnabled: true),
>>>> containerTemplate(
>>>> name: 'maven2',
>>>> image: "${registry}:5000/jenkins/slave-maven",
>>>> command: '/bin/bash',
>>>> args: '',
>>>> alwaysPullImage: true,
>>>> ttyEnabled: true)
>>>>
>>>> ])
>>>> {
>>>> node('kube-node') {
>>>> stage ('Compile') {
>>>> container ('maven1') {
>>>>
>>>> sleep(5)
>>>>
>>>>  }
>>>> }
>>>>
>>>>  parallel (
>>>>
>>>> "Unit": {
>>>>
>>>> container('maven1') {
>>>>
>>>> sleep(30)
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> },
>>>>
>>>>     "Integration": {
>>>>
>>>> container('maven2') {
>>>>
>>>> sleep(30)
>>>>
>>>>  }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> )
>>>>
>>>> }
>>>> }
>>>>
>>>>
>>>> However this won't work with splitTests where the number of parallel
>>>> branches is dynamic.
>>>>
>>>>
>>>> On 4 February 2017 at 09:04, Lionel Orellana <lione...@gmail.com>
>>>

Install breaks host autofs home dir

2017-02-14 Thread Lionel Orellana
Hi

I haven't been able to narrow this down more but basically the Ansible
installation is, sometimes, breaking my home dir.

My home dir is mounted with autofs from nfs. It normally looks like this.

-bash-4.2$ df -h | grep home
:// 303G  259G   44G  86% /home/userid


After running the installer I eventually lose access to my home directory
and see this error when trying to get in.

bash-4.2$ cd
-bash: cd: /home/: Too many levels of symbolic links

And my home directory is no longer mounted.

-bash-4.2$  df -h | grep home
-bash-4.2$

So whatever is now in the local /home/dir has some weird sym link problem.

Here's the kicker: If I restart docker the problem goes away.

Another colleague who ran the Ansible install had the same problem.

This is how we're running it.

sudo ansible-playbook --user=
--private-key=/home//.ssh/id_rsa --become -i ~/path/config
~/openshift-ansible/playbooks/byo/config.yml -vv

Any ideas?

Thanks

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


Is the registry now secure by default with ansible install?

2017-02-10 Thread Lionel Orellana
Hi

I haven't created any certs.

After an Ansible install using v.1.4.1 I simply added the integrated
registry to the docker daemon configuration and now docker info shows this
on the nodes:

Registries: 172.23.199.122:5000 (secure), registry.access.redhat.com
(secure), docker.io (secure)

An older cluster (v1.3) shows the integrated registry as insecure.

Looks like I don't have to worry about securing the registry in 1.4.1?

Thanks

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


Re: Adding Registry address to Docker's NO_PROXY list

2017-02-10 Thread Lionel Orellana
Seems like it's a known issue:
https://github.com/openshift/openshift-ansible/issues/1919

On 11 February 2017 at 13:53, Lionel Orellana <lione...@gmail.com> wrote:

> Hi
>
> After an ansible installation I always have to manually add Openshift's
> registry address to the docker NO_PROXY list in /etc/sysconfig/docker.
>
> If I don't builds fail with
>
> error: build error: Failed to push image: Get https://172.23.199.122:5000/
> v1/_ping: Service Unavailable
>
> I have this in my inventory
>
> openshift_http_proxy=:3128
> openshift_https_proxy=t:3128
> openshift_no_proxy=.
> openshift_generate_no_proxy_hosts=True
>
>
> But the registry address is not added to the no_proxy list.
>
> Is there another way to get it in there as part of the install?
>
> Thanks
>
> Lionel.
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Adding Registry address to Docker's NO_PROXY list

2017-02-10 Thread Lionel Orellana
Hi

After an ansible installation I always have to manually add Openshift's
registry address to the docker NO_PROXY list in /etc/sysconfig/docker.

If I don't builds fail with

error: build error: Failed to push image: Get
https://172.23.199.122:5000/v1/_ping: Service Unavailable

I have this in my inventory

openshift_http_proxy=:3128
openshift_https_proxy=t:3128
openshift_no_proxy=.
openshift_generate_no_proxy_hosts=True


But the registry address is not added to the no_proxy list.

Is there another way to get it in there as part of the install?

Thanks

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


Re: Template with Secret and Parameter

2017-01-30 Thread Lionel Orellana
My bad. It is working as expected.  Thank you all for your quick replies!

I think I had an old secret definition hanging around. It seems like "oc
delete all -l app=myapp" doesn't delete secrets that have the label?


On 31 January 2017 at 01:54, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Mon, Jan 30, 2017 at 9:47 AM, Jessica Forrester <jforr...@redhat.com>
> wrote:
>
>>
>>
>> On Mon, Jan 30, 2017 at 9:11 AM, Aleksandar Lazic <al...@me2digital.eu>
>> wrote:
>>
>>> Hi.
>>>
>>>   On Mon, 30 Jan 2017 10:04:35 +0100 Lionel Orellana <
>>> lione...@gmail.com> wrote 
>>>  > Put another way, how can I create a secret from user input?
>>>
>>> You will need to base64 encode the given string.
>>>
>>
>> Not when using stringData for the input, this gets converted to the
>> base64 encoded value on the server before being stored.  However,
>> stringData was not added until version 1.3 of origin, so if you are using a
>> an older origin server then you will have to use the data field instead and
>> base 64 encode the input.
>>
>>
>>
>>> echo -n 'pass'|base64
>>> This value is then the SVN_PASSWORD
>>>
>>> what's the ouput of?
>>>
>>> oc process -f ... -p ...
>>>
>>> BR aleks---
>>> Mit freundlichen Grüßen
>>> Aleksandar Lazic - ME2Digital e. U.
>>> https://me2digital.online/
>>> UID-Nr.: ATU71765716
>>> IBAN: AT27 1420 0200 1096 9086
>>> Firmenbuch: 462678 i
>>>
>>>
>>>  > On 30 January 2017 at 18:45, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>  > Hello
>>>  > I'm trying to create a secret as part of a template but the value of
>>> the secret should come from a parameter. Something like this:
>>>  > {"kind": "Template","apiVersion": "v1",...},
>>>  > "objects": [
>>>  > ... {"kind": "Secret","apiVersion":
>>> "v1","metadata": {"name": "svn-pwd",
>>> "creationTimestamp": null},"stringData": {
>>>   "password": "${SVN_PASSWORD}"}}],
>>> "parameters": [{  "name": "SVN_PASSWORD",  "value": "",
>>> "description": "Will be stored as a secret",  "required": true}  ]}
>>>  >
>>>  > The secret is getting created but it's not resolving the parameter
>>> value (i.e. the value is literally ${SVN_PASSWORD}).
>>>
>>
>> You can see some examples of us using Secrets in templates in our
>> examples folder, like:
>>
>> https://github.com/openshift/origin/blob/master/examples/db-
>> templates/mariadb-ephemeral-template.json
>>
>> Offhand I don't see anything wrong with how you have the parameter being
>> used in the Secret.  Ben?
>>
>
> ​yeah it looks right to me as well.  If you use the parameter elsewhere in
> your template (eg as an environment variable), does it get substituted?
> does your template contain any other parameters that are, or are not,
> getting substituted?
>
>
> ​
>
>
>>
>>
>>
>>>  > Is there a way to resolve the template parameter in the secret
>>> definition?
>>>  > Thanks
>>>  >
>>>  >
>>>  >  ___
>>>  > users mailing list
>>>  > users@lists.openshift.redhat.com
>>>  > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>  >
>>>
>>>
>>>
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Template with Secret and Parameter

2017-01-29 Thread Lionel Orellana
Hello

I'm trying to create a secret as part of a template but the value of the
secret should come from a parameter. Something like this:

{
"kind": "Template",
"apiVersion": "v1",
...
},
"objects": [
...
  {
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "svn-pwd",
"creationTimestamp": null
},
"stringData": {
"password": "${SVN_PASSWORD}"
}
}
],
  "parameters": [
{
  "name": "SVN_PASSWORD",
  "value": "",
  "description": "Will be stored as a secret",
  "required": true
}
  ]
}


The secret is getting created but it's not resolving the parameter value
(i.e. the value is literally ${SVN_PASSWORD}).

Is there a way to resolve the template parameter in the secret definition?

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


Adding secrets to Docker builds

2017-01-28 Thread Lionel Orellana
Hi

I have a Docker BuildConfig with an inline Dockerfile as the source.I'm
trying to add a secret to this build. The secret is called svn-pwd and
already exists in the project. It has a single key called 'password'.

In the inline Dockerfile I'm trying to find the mounted secret. It is
supposed to be in the build working dir (
https://trello.com/c/m5bPxwh4/643-8-allow-to-consume-secrets-in-builds) but
it's not.

In the Dockerfile below I don't see the secret when I do "RUN ls -la", and
"RUN cat password" fails.

apiVersion: v1
kind: BuildConfig
spec:
  source:
type: Dockerfile
dockerfile: "FROM  \n\nRUN ls -la \nRUN cat password"
secrets:
  -
secret:
  name: svn-pwd
  strategy:
type: Docker
dockerStrategy:
  env:
-
  name: xxx
  value: 'xxx'
  output:
to:
  kind: ImageStreamTag
  namespace: ipaustralia
  name: 'y:latest'


Should this working or is there something else I need to do?

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


Jenkins Windows Slave

2016-12-07 Thread Lionel Orellana
Hi

Is it possible to add an existing windows machine as a slave to a Jenkins
master running on Openshift?

I exposed the jnlp service with a route in Openshift and tried to use the
tunnel option with 1) a Java Web Start slave, 2) running the slave client
jar directly and 3) a Swarm slave. None of them worked. Seems like I just
can't use the tunnel to connect to the router.

The initial connection to the master works fine but then it fails to
connect to the jnlp service.

INFO: Attempting to connect to http://web-jenkins.ospoc.aipo.gov.au/
60787488-21
fe-4867-9251-cdba1c4b35b6 with ID 60a61643
Dec 07, 2016 9:24:16 PM hudson.remoting.jnlp.Main createEngine
INFO: Setting up slave: WS17072.production.prod-60a61643
Dec 07, 2016 9:24:16 PM hudson.remoting.jnlp.Main$CuiListener 
INFO: Jenkins agent is running in headless mode.
Dec 07, 2016 9:24:16 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Locating server among [http://web-jenkins.ospoc.aipo.gov.au/]
Dec 07, 2016 9:24:16 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Handshaking
Dec 07, 2016 9:24:16 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to jnlp-jenkins.ospoc.aipo.gov.au:80
Dec 07, 2016 9:24:16 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Server didn't accept the handshake: HTTP/1.0 400 Bad request
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to jnlp-jenkins.ospoc.aipo.gov.au:80
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP2-connect
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Server didn't accept the handshake: HTTP/1.0 400 Bad request
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to jnlp-jenkins.ospoc.aipo.gov.au:80
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP-connect
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Server didn't accept the handshake: HTTP/1.0 400 Bad request
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to jnlp-jenkins.ospoc.aipo.gov.au:80
Dec 07, 2016 9:24:17 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: The server rejected the connection: None of the protocols were
accepted
java.lang.Exception: The server rejected the connection: None of the
protocols w
ere accepted
at hudson.remoting.Engine.onConnectionRejected(Engine.java:366)
at hudson.remoting.Engine.run(Engine.java:338)


Is there a way to do this?

Thanks

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


Re: PV manual reclamation and recyling

2016-11-29 Thread Lionel Orellana
Thanks Clayton. Keep us posted.
On Wed., 30 Nov. 2016 at 2:48 am, Clayton Coleman <ccole...@redhat.com>
wrote:

> It's likely, don't have an eta yet while the scope of the pick is assessed.
>
> On Thu, Nov 24, 2016 at 5:52 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> This is a pretty bad issue in Kubernetes. We are talking about deleting
> data from NFS volumes. Lucky for me I'm just doing a POC. Is this not
> considered bad enough to warrant a patch release for Origin 1.3.x?
>
> Cheers
>
> Lionel.
>
> On 19 November 2016 at 07:38, Lionel Orellana <lione...@gmail.com> wrote:
>
> The only "released" version of Openshift that includes Kubernetes 1.3.6 is
> v1.4.0.-alpha1. I don't want to upgrade to an alpha1 release.
>
> Can I request a patch of Openshift Origin to include Kubernetes 1.3.6 or
> higher? ( the Kubernetes 1.3 branch is up to 1.3.10).
>
> On 19 November 2016 at 07:26, Alex Wauck <alexwa...@exosite.com> wrote:
>
> OpenShift is a distribution of Kubernetes, so I don't think you can
> upgrade Kubernetes without upgrading OpenShift.
>
> On Fri, Nov 18, 2016 at 1:52 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> So the fix is on Kubernetes 1.3.6. The upgrade guide you mention is for
> Openshift as a whole unless I'm missing something.
> On Sat., 19 Nov. 2016 at 12:29 am, Mark Turansky <mtura...@redhat.com>
> wrote:
>
> Good find on that bug. Our upgrade guide can help you get started on a
> fix.
>
>
> https://docs.openshift.com/container-platform/3.3/install_config/upgrading/index.html
>
> Mark
>
> On Fri, Nov 18, 2016 at 3:13 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>
> This sounds very very familiar:
> https://github.com/kubernetes/kubernetes/issues/30637
>
> Particularly comment:
> https://github.com/kubernetes/kubernetes/issues/30637#issuecomment-243276076
>
> That is a nasty bug. How can I upgrade Kubernetes in my cluster?
>
> My current versions are
>
> -bash-4.2$ oc version
> oc v1.3.0
> kubernetes v1.3.0+52492b4
> features: Basic-Auth GSSAPI Kerberos SPNEGO
>
> Server https://poc-docker01.aipo.gov.au:8443
> openshift v1.3.0
> kubernetes v1.3.0+52492b4
>
>
> On 18 November 2016 at 18:18, Lionel Orellana <lione...@gmail.com> wrote:
>
> Files in other dirs in the same NFS server don't get deleted (e.g.  name>/poc_runtime/test/)
>
> There is something in my Openshift node deleting files in  name>/poc_runtime/evs as soon as I put them there!
>
> On 18 November 2016 at 18:04, Lionel Orellana <lione...@gmail.com> wrote:
>
>
> In fact, whatever is deleting my files is still doing it:
>
> [root@poc-docker03 evs]# touch x
> [root@poc-docker03 evs]# ls
> [root@poc-docker03 evs]#
>
> evs is a path on an NFS volume that I have added directly to some
> deployment configs
>
>  -
>   name: evs
>   nfs:
> server: 
> path: /poc_runtime/evs
>
> If I stop the origin-service on one particular node the file doesn't
> disappear.
>
> [root@poc-docker03 evs]# touch x
> [root@poc-docker03 evs]# ls
> x
> [root@poc-docker03 evs]#
>
> When I restart the origin-node service I see a lot of errors like this
>
>  Failed cleaning pods: [remove
> /var/lib/origin/openshift.local.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/
> kubernetes.io~nfs device or resource bus
>  Failed to remove orphaned pod x dir; err: remove
> /var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io
> ~nfs/*evs*: device or resource bus
>
> Despite the fact that the error says that it couldn't remove it, what
> exactly is it trying to do here? Is it possible that this process
> previously deleted the data in the evs folder?
>
>
>
>
> On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com> wrote:
>
> What about NFS volumes added directly in build configs.
>
> volumes:
> -
>   name: jenkins-volume-1
>   nfs:
> server: 
> path: /poc_runtime/jenkins/home
>
>
> We just restarted all the servers hosting my openshift cluster and the all
> data in the path above disappeared. Simply by restarting the host VM!
>
>
>
> On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com> wrote:
>
> Thanks Mark
>
> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:
>
>
>
> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> Hi,
>
> Couple of questions regarding Persistent Volumes, in particular NFS ones.
>
> 1) If I have a PV config

Re: PV manual reclamation and recyling

2016-11-24 Thread Lionel Orellana
This is a pretty bad issue in Kubernetes. We are talking about deleting
data from NFS volumes. Lucky for me I'm just doing a POC. Is this not
considered bad enough to warrant a patch release for Origin 1.3.x?

Cheers

Lionel.

On 19 November 2016 at 07:38, Lionel Orellana <lione...@gmail.com> wrote:

> The only "released" version of Openshift that includes Kubernetes 1.3.6 is
> v1.4.0.-alpha1. I don't want to upgrade to an alpha1 release.
>
> Can I request a patch of Openshift Origin to include Kubernetes 1.3.6 or
> higher? ( the Kubernetes 1.3 branch is up to 1.3.10).
>
> On 19 November 2016 at 07:26, Alex Wauck <alexwa...@exosite.com> wrote:
>
>> OpenShift is a distribution of Kubernetes, so I don't think you can
>> upgrade Kubernetes without upgrading OpenShift.
>>
>> On Fri, Nov 18, 2016 at 1:52 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> So the fix is on Kubernetes 1.3.6. The upgrade guide you mention is for
>>> Openshift as a whole unless I'm missing something.
>>> On Sat., 19 Nov. 2016 at 12:29 am, Mark Turansky <mtura...@redhat.com>
>>> wrote:
>>>
>>>> Good find on that bug. Our upgrade guide can help you get started on a
>>>> fix.
>>>>
>>>> https://docs.openshift.com/container-platform/3.3/install_co
>>>> nfig/upgrading/index.html
>>>>
>>>> Mark
>>>>
>>>> On Fri, Nov 18, 2016 at 3:13 AM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>> This sounds very very familiar: https://github.com/k
>>>> ubernetes/kubernetes/issues/30637
>>>>
>>>> Particularly comment: https://github.com/ku
>>>> bernetes/kubernetes/issues/30637#issuecomment-243276076
>>>>
>>>> That is a nasty bug. How can I upgrade Kubernetes in my cluster?
>>>>
>>>> My current versions are
>>>>
>>>> -bash-4.2$ oc version
>>>> oc v1.3.0
>>>> kubernetes v1.3.0+52492b4
>>>> features: Basic-Auth GSSAPI Kerberos SPNEGO
>>>>
>>>> Server https://poc-docker01.aipo.gov.au:8443
>>>> openshift v1.3.0
>>>> kubernetes v1.3.0+52492b4
>>>>
>>>>
>>>> On 18 November 2016 at 18:18, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>> Files in other dirs in the same NFS server don't get deleted (e.g.
>>>> /poc_runtime/test/)
>>>>
>>>> There is something in my Openshift node deleting files in >>> name>/poc_runtime/evs as soon as I put them there!
>>>>
>>>> On 18 November 2016 at 18:04, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>> In fact, whatever is deleting my files is still doing it:
>>>>
>>>> [root@poc-docker03 evs]# touch x
>>>> [root@poc-docker03 evs]# ls
>>>> [root@poc-docker03 evs]#
>>>>
>>>> evs is a path on an NFS volume that I have added directly to some
>>>> deployment configs
>>>>
>>>>  -
>>>>   name: evs
>>>>   nfs:
>>>> server: 
>>>> path: /poc_runtime/evs
>>>>
>>>> If I stop the origin-service on one particular node the file doesn't
>>>> disappear.
>>>>
>>>> [root@poc-docker03 evs]# touch x
>>>> [root@poc-docker03 evs]# ls
>>>> x
>>>> [root@poc-docker03 evs]#
>>>>
>>>> When I restart the origin-node service I see a lot of errors like this
>>>>
>>>>  Failed cleaning pods: [remove /var/lib/origin/openshift.loca
>>>> l.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/
>>>> kubernetes.io~nfs device or resource bus
>>>>  Failed to remove orphaned pod x dir; err: remove
>>>> /var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io
>>>> ~nfs/*evs*: device or resource bus
>>>>
>>>> Despite the fact that the error says that it couldn't remove it, what
>>>> exactly is it trying to do here? Is it possible that this process
>>>> previously deleted the data in the evs folder?
>>>>
>>>>
>>>>
>>>>
>>>> On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>> What about NFS volumes added directly in build

Re: PV manual reclamation and recyling

2016-11-18 Thread Lionel Orellana
The only "released" version of Openshift that includes Kubernetes 1.3.6 is
v1.4.0.-alpha1. I don't want to upgrade to an alpha1 release.

Can I request a patch of Openshift Origin to include Kubernetes 1.3.6 or
higher? ( the Kubernetes 1.3 branch is up to 1.3.10).

On 19 November 2016 at 07:26, Alex Wauck <alexwa...@exosite.com> wrote:

> OpenShift is a distribution of Kubernetes, so I don't think you can
> upgrade Kubernetes without upgrading OpenShift.
>
> On Fri, Nov 18, 2016 at 1:52 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> So the fix is on Kubernetes 1.3.6. The upgrade guide you mention is for
>> Openshift as a whole unless I'm missing something.
>> On Sat., 19 Nov. 2016 at 12:29 am, Mark Turansky <mtura...@redhat.com>
>> wrote:
>>
>>> Good find on that bug. Our upgrade guide can help you get started on a
>>> fix.
>>>
>>> https://docs.openshift.com/container-platform/3.3/install_
>>> config/upgrading/index.html
>>>
>>> Mark
>>>
>>> On Fri, Nov 18, 2016 at 3:13 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>
>>> This sounds very very familiar: https://github.com/k
>>> ubernetes/kubernetes/issues/30637
>>>
>>> Particularly comment: https://github.com/ku
>>> bernetes/kubernetes/issues/30637#issuecomment-243276076
>>>
>>> That is a nasty bug. How can I upgrade Kubernetes in my cluster?
>>>
>>> My current versions are
>>>
>>> -bash-4.2$ oc version
>>> oc v1.3.0
>>> kubernetes v1.3.0+52492b4
>>> features: Basic-Auth GSSAPI Kerberos SPNEGO
>>>
>>> Server https://poc-docker01.aipo.gov.au:8443
>>> openshift v1.3.0
>>> kubernetes v1.3.0+52492b4
>>>
>>>
>>> On 18 November 2016 at 18:18, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>> Files in other dirs in the same NFS server don't get deleted (e.g.
>>> /poc_runtime/test/)
>>>
>>> There is something in my Openshift node deleting files in >> name>/poc_runtime/evs as soon as I put them there!
>>>
>>> On 18 November 2016 at 18:04, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>
>>> In fact, whatever is deleting my files is still doing it:
>>>
>>> [root@poc-docker03 evs]# touch x
>>> [root@poc-docker03 evs]# ls
>>> [root@poc-docker03 evs]#
>>>
>>> evs is a path on an NFS volume that I have added directly to some
>>> deployment configs
>>>
>>>  -
>>>   name: evs
>>>   nfs:
>>> server: 
>>> path: /poc_runtime/evs
>>>
>>> If I stop the origin-service on one particular node the file doesn't
>>> disappear.
>>>
>>> [root@poc-docker03 evs]# touch x
>>> [root@poc-docker03 evs]# ls
>>> x
>>> [root@poc-docker03 evs]#
>>>
>>> When I restart the origin-node service I see a lot of errors like this
>>>
>>>  Failed cleaning pods: [remove /var/lib/origin/openshift.loca
>>> l.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/
>>> kubernetes.io~nfs device or resource bus
>>>  Failed to remove orphaned pod x dir; err: remove
>>> /var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io
>>> ~nfs/*evs*: device or resource bus
>>>
>>> Despite the fact that the error says that it couldn't remove it, what
>>> exactly is it trying to do here? Is it possible that this process
>>> previously deleted the data in the evs folder?
>>>
>>>
>>>
>>>
>>> On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>> What about NFS volumes added directly in build configs.
>>>
>>> volumes:
>>> -
>>>   name: jenkins-volume-1
>>>   nfs:
>>> server: 
>>> path: /poc_runtime/jenkins/home
>>>
>>>
>>> We just restarted all the servers hosting my openshift cluster and the
>>> all data in the path above disappeared. Simply by restarting the host VM!
>>>
>>>
>>>
>>> On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>> Thanks Mark
>>>
>>> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:
>>>
>>>
>

Re: PV manual reclamation and recyling

2016-11-18 Thread Lionel Orellana
So the fix is on Kubernetes 1.3.6. The upgrade guide you mention is for
Openshift as a whole unless I'm missing something.
On Sat., 19 Nov. 2016 at 12:29 am, Mark Turansky <mtura...@redhat.com>
wrote:

> Good find on that bug. Our upgrade guide can help you get started on a
> fix.
>
>
> https://docs.openshift.com/container-platform/3.3/install_config/upgrading/index.html
>
> Mark
>
> On Fri, Nov 18, 2016 at 3:13 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>
> This sounds very very familiar:
> https://github.com/kubernetes/kubernetes/issues/30637
>
> Particularly comment:
> https://github.com/kubernetes/kubernetes/issues/30637#issuecomment-243276076
>
> That is a nasty bug. How can I upgrade Kubernetes in my cluster?
>
> My current versions are
>
> -bash-4.2$ oc version
> oc v1.3.0
> kubernetes v1.3.0+52492b4
> features: Basic-Auth GSSAPI Kerberos SPNEGO
>
> Server https://poc-docker01.aipo.gov.au:8443
> openshift v1.3.0
> kubernetes v1.3.0+52492b4
>
>
> On 18 November 2016 at 18:18, Lionel Orellana <lione...@gmail.com> wrote:
>
> Files in other dirs in the same NFS server don't get deleted (e.g.  name>/poc_runtime/test/)
>
> There is something in my Openshift node deleting files in  name>/poc_runtime/evs as soon as I put them there!
>
> On 18 November 2016 at 18:04, Lionel Orellana <lione...@gmail.com> wrote:
>
>
> In fact, whatever is deleting my files is still doing it:
>
> [root@poc-docker03 evs]# touch x
> [root@poc-docker03 evs]# ls
> [root@poc-docker03 evs]#
>
> evs is a path on an NFS volume that I have added directly to some
> deployment configs
>
>  -
>   name: evs
>   nfs:
> server: 
> path: /poc_runtime/evs
>
> If I stop the origin-service on one particular node the file doesn't
> disappear.
>
> [root@poc-docker03 evs]# touch x
> [root@poc-docker03 evs]# ls
> x
> [root@poc-docker03 evs]#
>
> When I restart the origin-node service I see a lot of errors like this
>
>  Failed cleaning pods: [remove
> /var/lib/origin/openshift.local.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/
> kubernetes.io~nfs device or resource bus
>  Failed to remove orphaned pod x dir; err: remove
> /var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io
> ~nfs/*evs*: device or resource bus
>
> Despite the fact that the error says that it couldn't remove it, what
> exactly is it trying to do here? Is it possible that this process
> previously deleted the data in the evs folder?
>
>
>
>
> On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com> wrote:
>
> What about NFS volumes added directly in build configs.
>
> volumes:
> -
>   name: jenkins-volume-1
>   nfs:
> server: 
> path: /poc_runtime/jenkins/home
>
>
> We just restarted all the servers hosting my openshift cluster and the all
> data in the path above disappeared. Simply by restarting the host VM!
>
>
>
> On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com> wrote:
>
> Thanks Mark
>
> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:
>
>
>
> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> Hi,
>
> Couple of questions regarding Persistent Volumes, in particular NFS ones.
>
> 1) If I have a PV configured with the Retain policy it is not clear to me
> how this PV can be reused after the bound PVC is deleted. Deleting the PVC
> makes the PV status "Released". How do I make it "Available" again without
> losing the data?
>
>
> You can keep the PVC around longer if you intend to reuse it between pods.
> There is no way for a PV to go from Released to Available again in your
> scenario. You would have to delete and recreate the PV. It's a pointer to
> real storage (the NFS share), so you're just recreating the pointer. The
> data in the NFS volume itself is untouched.
>
>
>
>
> 2) Is there anything (e.g. all nodes crashing due to some underlying
> infrastructure failure) that would cause the data in a "Retain" volume to
> be wiped out? We had a problem with all our vmware servers  (where I host
> my openshift POC)  and all my NFS mounted volumes were wiped out. The
> storage guys assure me that nothing at their end caused that and it must
> have been a running process that did it.
>
>
> "Retain" is just a flag to the recycling process to leave that PV alone
> when it's Released. The PV's retention policy wouldn't cause everything to
> be deleted

Re: JBoss cluster

2016-11-18 Thread Lionel Orellana
Correct.
On Sat., 19 Nov. 2016 at 12:29 am, Marko Lukša <marko.lu...@gmail.com>
wrote:

> Hi,
>
> so clustering is working, but you still see the warning in the log? If so,
> we'd like to fix this.
>
> I'm assuming you're setting the HTTP_PROXY environment variable? As you've
> pointed out, since we're calling curl without --no-proxy, it can't access
> the API server. The actual kube-ping code, on the other hand, can access it
> because it bypasses the proxy.
>
> M.
>
>
> On 18. 11. 2016 02:32, Lionel Orellana wrote:
>
> I deployed a distributable war and got the output I was looking for. All
> good with the world. Thanks.
>
> On 18 November 2016 at 08:29, Lionel Orellana <lione...@gmail.com> wrote:
>
> But I can't tell if the second replica joined the cluster created by the
> first.
>
> I'm expecting to see "Number of cluster members: x" in the logs but it's
> not showing in any of the two instances.
>
> On 17 November 2016 at 22:55, Lionel Orellana <lione...@gmail.com> wrote:
>
> Thanks Frederick. I have done that.
>
> On Thu., 17 Nov. 2016 at 10:48 pm, Frederic Giloux <fgil...@redhat.com>
> wrote:
>
> Hi Lionel,
>
> JBoss on OpenShift uses JGroups Kube_ping to discover the other members of
> the cluster. This actually calls the Kubernetes REST API. Therefore you
> need to have the proper rights allocated to your service account. More
> information here:
> https://access.redhat.com/documentation/en/red-hat-xpaas/0/single/red-hat-xpaas-eap-image/#clustering
>
> Best Regards,
>
> Frédéric
>
>
> On Thu, Nov 17, 2016 at 11:58 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> Hi,
>
> I'm trying to run Jboss cluster using the eap64-basic-s2i v1.3.2 template
> on Origin 1.3.
>
> The application built and deployed fined. The second one started fine but
> I can't tell if it joined the existing cluster. I was expecting to see an
> output along the lines of "number of members in the cluster: 2" which I
> have seen in the past with Jboss.
>
> There is a warning at the begining of the startup logs:
>
> "WARNING: Service account unable to test permissions to view pods in
> kubernetes (HTTP 000). Clustering will be unavailable. Please refer to the
> documentation for configuration."
>
> But looking at the ha.sh launch script this is just
> the check_view_pods_permission function using curl without --no-proxy. As
> far as I can tell this doesn't affect anything.
>
> So what do I need to look for to confirm that the second instance joined
> the cluster correctly? I am concerned that the proxy might be getting in
> the way somewhere else.
>
> Thanks
>
> Lionel
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
>
>
> --
> *Frédéric Giloux*
> Senior Middleware Consultant
>
> Red Hat GmbH
> MesseTurm, Friedrich-Ebert-Anlage 49, 60308 Frankfurt am Main
>
> Mobile: +49 (0) 174 1724661 
> E-Mail: fgil...@redhat.com, http://www.redhat.de/
>
> Delivering value year after year
> Red Hat ranks # 1 in value among software vendors
> http://www.redhat.com/promo/vendor/
>
> Freedom...Courage...Commitment...Accountability
> 
> Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243
> Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham, Michael
> O'Neill
>
>
>
>
>
> ___
> users mailing 
> listusers@lists.openshift.redhat.comhttp://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: PV manual reclamation and recyling

2016-11-18 Thread Lionel Orellana
This sounds very very familiar:
https://github.com/kubernetes/kubernetes/issues/30637

Particularly comment:
https://github.com/kubernetes/kubernetes/issues/30637#issuecomment-243276076

That is a nasty bug. How can I upgrade Kubernetes in my cluster?

My current versions are

-bash-4.2$ oc version
oc v1.3.0
kubernetes v1.3.0+52492b4
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://poc-docker01.aipo.gov.au:8443
openshift v1.3.0
kubernetes v1.3.0+52492b4


On 18 November 2016 at 18:18, Lionel Orellana <lione...@gmail.com> wrote:

> Files in other dirs in the same NFS server don't get deleted (e.g.  name>/poc_runtime/test/)
>
> There is something in my Openshift node deleting files in  name>/poc_runtime/evs as soon as I put them there!
>
> On 18 November 2016 at 18:04, Lionel Orellana <lione...@gmail.com> wrote:
>
>>
>> In fact, whatever is deleting my files is still doing it:
>>
>> [root@poc-docker03 evs]# touch x
>> [root@poc-docker03 evs]# ls
>> [root@poc-docker03 evs]#
>>
>> evs is a path on an NFS volume that I have added directly to some
>> deployment configs
>>
>>  -
>>   name: evs
>>   nfs:
>> server: 
>> path: /poc_runtime/evs
>>
>> If I stop the origin-service on one particular node the file doesn't
>> disappear.
>>
>> [root@poc-docker03 evs]# touch x
>> [root@poc-docker03 evs]# ls
>> x
>> [root@poc-docker03 evs]#
>>
>> When I restart the origin-node service I see a lot of errors like this
>>
>>  Failed cleaning pods: [remove /var/lib/origin/openshift.loca
>> l.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/kubernetes.io~nfs
>> device or resource bus
>>  Failed to remove orphaned pod x dir; err: remove
>> /var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io
>> ~nfs/*evs*: device or resource bus
>>
>> Despite the fact that the error says that it couldn't remove it, what
>> exactly is it trying to do here? Is it possible that this process
>> previously deleted the data in the evs folder?
>>
>>
>>
>>
>> On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> What about NFS volumes added directly in build configs.
>>>
>>> volumes:
>>> -
>>>   name: jenkins-volume-1
>>>   nfs:
>>> server: 
>>> path: /poc_runtime/jenkins/home
>>>
>>>
>>> We just restarted all the servers hosting my openshift cluster and the
>>> all data in the path above disappeared. Simply by restarting the host VM!
>>>
>>>
>>>
>>> On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Thanks Mark
>>>>
>>>> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Couple of questions regarding Persistent Volumes, in particular NFS
>>>>>> ones.
>>>>>>
>>>>>> 1) If I have a PV configured with the Retain policy it is not clear
>>>>>> to me how this PV can be reused after the bound PVC is deleted. Deleting
>>>>>> the PVC makes the PV status "Released". How do I make it "Available" 
>>>>>> again
>>>>>> without losing the data?
>>>>>>
>>>>>
>>>>> You can keep the PVC around longer if you intend to reuse it between
>>>>> pods. There is no way for a PV to go from Released to Available again in
>>>>> your scenario. You would have to delete and recreate the PV. It's a 
>>>>> pointer
>>>>> to real storage (the NFS share), so you're just recreating the pointer. 
>>>>> The
>>>>> data in the NFS volume itself is untouched.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 2) Is there anything (e.g. all nodes crashing due to some underlying
>>>>>> infrastructure failure) that would cause the data in a "Retain" volume to
>>>>>> be wiped out? We had a problem with all our vmware servers  (where I host
>>>>>> my openshift POC)  and all my NFS mounted volumes were wiped out. The
>>>>>> storage guys assure me that nothing at their end caused that and it must
>>>>>> have been a running process that did it.
>>>>>>
>>>>>
>>>>> "Retain" is just a flag to the recycling process to leave that PV
>>>>> alone when it's Released. The PV's retention policy wouldn't cause
>>>>> everything to be deleted. NFS volumes on the node are no different than if
>>>>> you called "mount" yourself. There is nothing inherent in OpenShift itself
>>>>> that is running in that share that would wipe out data.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Lionel.
>>>>>>
>>>>>> ___
>>>>>> users mailing list
>>>>>> users@lists.openshift.redhat.com
>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: PV manual reclamation and recyling

2016-11-17 Thread Lionel Orellana
Files in other dirs in the same NFS server don't get deleted (e.g. /poc_runtime/test/)

There is something in my Openshift node deleting files in /poc_runtime/evs as soon as I put them there!

On 18 November 2016 at 18:04, Lionel Orellana <lione...@gmail.com> wrote:

>
> In fact, whatever is deleting my files is still doing it:
>
> [root@poc-docker03 evs]# touch x
> [root@poc-docker03 evs]# ls
> [root@poc-docker03 evs]#
>
> evs is a path on an NFS volume that I have added directly to some
> deployment configs
>
>  -
>   name: evs
>   nfs:
> server: 
> path: /poc_runtime/evs
>
> If I stop the origin-service on one particular node the file doesn't
> disappear.
>
> [root@poc-docker03 evs]# touch x
> [root@poc-docker03 evs]# ls
> x
> [root@poc-docker03 evs]#
>
> When I restart the origin-node service I see a lot of errors like this
>
>  Failed cleaning pods: [remove /var/lib/origin/openshift.
> local.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/
> kubernetes.io~nfs device or resource bus
>  Failed to remove orphaned pod x dir; err: remove
> /var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io
> ~nfs/*evs*: device or resource bus
>
> Despite the fact that the error says that it couldn't remove it, what
> exactly is it trying to do here? Is it possible that this process
> previously deleted the data in the evs folder?
>
>
>
>
> On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com> wrote:
>
>> What about NFS volumes added directly in build configs.
>>
>> volumes:
>> -
>>   name: jenkins-volume-1
>>   nfs:
>> server: 
>> path: /poc_runtime/jenkins/home
>>
>>
>> We just restarted all the servers hosting my openshift cluster and the
>> all data in the path above disappeared. Simply by restarting the host VM!
>>
>>
>>
>> On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> Thanks Mark
>>>
>>> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Couple of questions regarding Persistent Volumes, in particular NFS
>>>>> ones.
>>>>>
>>>>> 1) If I have a PV configured with the Retain policy it is not clear to
>>>>> me how this PV can be reused after the bound PVC is deleted. Deleting the
>>>>> PVC makes the PV status "Released". How do I make it "Available" again
>>>>> without losing the data?
>>>>>
>>>>
>>>> You can keep the PVC around longer if you intend to reuse it between
>>>> pods. There is no way for a PV to go from Released to Available again in
>>>> your scenario. You would have to delete and recreate the PV. It's a pointer
>>>> to real storage (the NFS share), so you're just recreating the pointer. The
>>>> data in the NFS volume itself is untouched.
>>>>
>>>>
>>>>
>>>>>
>>>>> 2) Is there anything (e.g. all nodes crashing due to some underlying
>>>>> infrastructure failure) that would cause the data in a "Retain" volume to
>>>>> be wiped out? We had a problem with all our vmware servers  (where I host
>>>>> my openshift POC)  and all my NFS mounted volumes were wiped out. The
>>>>> storage guys assure me that nothing at their end caused that and it must
>>>>> have been a running process that did it.
>>>>>
>>>>
>>>> "Retain" is just a flag to the recycling process to leave that PV alone
>>>> when it's Released. The PV's retention policy wouldn't cause everything to
>>>> be deleted. NFS volumes on the node are no different than if you called
>>>> "mount" yourself. There is nothing inherent in OpenShift itself that is
>>>> running in that share that would wipe out data.
>>>>
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Lionel.
>>>>>
>>>>> ___
>>>>> users mailing list
>>>>> users@lists.openshift.redhat.com
>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>
>>>>>
>>>>
>>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: PV manual reclamation and recyling

2016-11-17 Thread Lionel Orellana
In fact, whatever is deleting my files is still doing it:

[root@poc-docker03 evs]# touch x
[root@poc-docker03 evs]# ls
[root@poc-docker03 evs]#

evs is a path on an NFS volume that I have added directly to some
deployment configs

 -
  name: evs
  nfs:
server: 
path: /poc_runtime/evs

If I stop the origin-service on one particular node the file doesn't
disappear.

[root@poc-docker03 evs]# touch x
[root@poc-docker03 evs]# ls
x
[root@poc-docker03 evs]#

When I restart the origin-node service I see a lot of errors like this

 Failed cleaning pods: [remove
/var/lib/origin/openshift.local.volumes/pods/1b7e3a16-ab08-11e6-8618-005056915814/volumes/
kubernetes.io~nfs device or resource bus
 Failed to remove orphaned pod x dir; err: remove
/var/lib/origin/openshift.local.volumes/pods//volumes/kubernetes.io~nfs/
*evs*: device or resource bus

Despite the fact that the error says that it couldn't remove it, what
exactly is it trying to do here? Is it possible that this process
previously deleted the data in the evs folder?




On 18 November 2016 at 16:45, Lionel Orellana <lione...@gmail.com> wrote:

> What about NFS volumes added directly in build configs.
>
> volumes:
> -
>   name: jenkins-volume-1
>   nfs:
> server: 
> path: /poc_runtime/jenkins/home
>
>
> We just restarted all the servers hosting my openshift cluster and the all
> data in the path above disappeared. Simply by restarting the host VM!
>
>
>
> On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com> wrote:
>
>> Thanks Mark
>>
>> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Couple of questions regarding Persistent Volumes, in particular NFS
>>>> ones.
>>>>
>>>> 1) If I have a PV configured with the Retain policy it is not clear to
>>>> me how this PV can be reused after the bound PVC is deleted. Deleting the
>>>> PVC makes the PV status "Released". How do I make it "Available" again
>>>> without losing the data?
>>>>
>>>
>>> You can keep the PVC around longer if you intend to reuse it between
>>> pods. There is no way for a PV to go from Released to Available again in
>>> your scenario. You would have to delete and recreate the PV. It's a pointer
>>> to real storage (the NFS share), so you're just recreating the pointer. The
>>> data in the NFS volume itself is untouched.
>>>
>>>
>>>
>>>>
>>>> 2) Is there anything (e.g. all nodes crashing due to some underlying
>>>> infrastructure failure) that would cause the data in a "Retain" volume to
>>>> be wiped out? We had a problem with all our vmware servers  (where I host
>>>> my openshift POC)  and all my NFS mounted volumes were wiped out. The
>>>> storage guys assure me that nothing at their end caused that and it must
>>>> have been a running process that did it.
>>>>
>>>
>>> "Retain" is just a flag to the recycling process to leave that PV alone
>>> when it's Released. The PV's retention policy wouldn't cause everything to
>>> be deleted. NFS volumes on the node are no different than if you called
>>> "mount" yourself. There is nothing inherent in OpenShift itself that is
>>> running in that share that would wipe out data.
>>>
>>>
>>>
>>>>
>>>> Thanks
>>>>
>>>> Lionel.
>>>>
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: PV manual reclamation and recyling

2016-11-17 Thread Lionel Orellana
What about NFS volumes added directly in build configs.

volumes:
-
  name: jenkins-volume-1
  nfs:
server: 
path: /poc_runtime/jenkins/home


We just restarted all the servers hosting my openshift cluster and the all
data in the path above disappeared. Simply by restarting the host VM!



On 18 November 2016 at 16:19, Lionel Orellana <lione...@gmail.com> wrote:

> Thanks Mark
>
> On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:
>
>>
>>
>> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Couple of questions regarding Persistent Volumes, in particular NFS
>>> ones.
>>>
>>> 1) If I have a PV configured with the Retain policy it is not clear to
>>> me how this PV can be reused after the bound PVC is deleted. Deleting the
>>> PVC makes the PV status "Released". How do I make it "Available" again
>>> without losing the data?
>>>
>>
>> You can keep the PVC around longer if you intend to reuse it between
>> pods. There is no way for a PV to go from Released to Available again in
>> your scenario. You would have to delete and recreate the PV. It's a pointer
>> to real storage (the NFS share), so you're just recreating the pointer. The
>> data in the NFS volume itself is untouched.
>>
>>
>>
>>>
>>> 2) Is there anything (e.g. all nodes crashing due to some underlying
>>> infrastructure failure) that would cause the data in a "Retain" volume to
>>> be wiped out? We had a problem with all our vmware servers  (where I host
>>> my openshift POC)  and all my NFS mounted volumes were wiped out. The
>>> storage guys assure me that nothing at their end caused that and it must
>>> have been a running process that did it.
>>>
>>
>> "Retain" is just a flag to the recycling process to leave that PV alone
>> when it's Released. The PV's retention policy wouldn't cause everything to
>> be deleted. NFS volumes on the node are no different than if you called
>> "mount" yourself. There is nothing inherent in OpenShift itself that is
>> running in that share that would wipe out data.
>>
>>
>>
>>>
>>> Thanks
>>>
>>> Lionel.
>>>
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: PV manual reclamation and recyling

2016-11-17 Thread Lionel Orellana
Thanks Mark

On 18 November 2016 at 15:09, Mark Turansky <mtura...@redhat.com> wrote:

>
>
> On Thu, Nov 17, 2016 at 10:41 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Couple of questions regarding Persistent Volumes, in particular NFS ones.
>>
>> 1) If I have a PV configured with the Retain policy it is not clear to me
>> how this PV can be reused after the bound PVC is deleted. Deleting the PVC
>> makes the PV status "Released". How do I make it "Available" again without
>> losing the data?
>>
>
> You can keep the PVC around longer if you intend to reuse it between pods.
> There is no way for a PV to go from Released to Available again in your
> scenario. You would have to delete and recreate the PV. It's a pointer to
> real storage (the NFS share), so you're just recreating the pointer. The
> data in the NFS volume itself is untouched.
>
>
>
>>
>> 2) Is there anything (e.g. all nodes crashing due to some underlying
>> infrastructure failure) that would cause the data in a "Retain" volume to
>> be wiped out? We had a problem with all our vmware servers  (where I host
>> my openshift POC)  and all my NFS mounted volumes were wiped out. The
>> storage guys assure me that nothing at their end caused that and it must
>> have been a running process that did it.
>>
>
> "Retain" is just a flag to the recycling process to leave that PV alone
> when it's Released. The PV's retention policy wouldn't cause everything to
> be deleted. NFS volumes on the node are no different than if you called
> "mount" yourself. There is nothing inherent in OpenShift itself that is
> running in that share that would wipe out data.
>
>
>
>>
>> Thanks
>>
>> Lionel.
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


PV manual reclamation and recyling

2016-11-17 Thread Lionel Orellana
Hi,

Couple of questions regarding Persistent Volumes, in particular NFS ones.

1) If I have a PV configured with the Retain policy it is not clear to me
how this PV can be reused after the bound PVC is deleted. Deleting the PVC
makes the PV status "Released". How do I make it "Available" again without
losing the data?

2) Is there anything (e.g. all nodes crashing due to some underlying
infrastructure failure) that would cause the data in a "Retain" volume to
be wiped out? We had a problem with all our vmware servers  (where I host
my openshift POC)  and all my NFS mounted volumes were wiped out. The
storage guys assure me that nothing at their end caused that and it must
have been a running process that did it.

Thanks

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


Re: JBoss cluster

2016-11-17 Thread Lionel Orellana
I deployed a distributable war and got the output I was looking for. All
good with the world. Thanks.

On 18 November 2016 at 08:29, Lionel Orellana <lione...@gmail.com> wrote:

> But I can't tell if the second replica joined the cluster created by the
> first.
>
> I'm expecting to see "Number of cluster members: x" in the logs but it's
> not showing in any of the two instances.
>
> On 17 November 2016 at 22:55, Lionel Orellana <lione...@gmail.com> wrote:
>
>> Thanks Frederick. I have done that.
>>
>> On Thu., 17 Nov. 2016 at 10:48 pm, Frederic Giloux <fgil...@redhat.com>
>> wrote:
>>
>>> Hi Lionel,
>>>
>>> JBoss on OpenShift uses JGroups Kube_ping to discover the other members
>>> of the cluster. This actually calls the Kubernetes REST API. Therefore you
>>> need to have the proper rights allocated to your service account. More
>>> information here: https://access.redhat.com/docu
>>> mentation/en/red-hat-xpaas/0/single/red-hat-xpaas-eap-image/#clustering
>>>
>>> Best Regards,
>>>
>>> Frédéric
>>>
>>>
>>> On Thu, Nov 17, 2016 at 11:58 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to run Jboss cluster using the eap64-basic-s2i v1.3.2
>>> template on Origin 1.3.
>>>
>>> The application built and deployed fined. The second one started fine
>>> but I can't tell if it joined the existing cluster. I was expecting to see
>>> an output along the lines of "number of members in the cluster: 2" which I
>>> have seen in the past with Jboss.
>>>
>>> There is a warning at the begining of the startup logs:
>>>
>>> "WARNING: Service account unable to test permissions to view pods in
>>> kubernetes (HTTP 000). Clustering will be unavailable. Please refer to the
>>> documentation for configuration."
>>>
>>> But looking at the ha.sh launch script this is just
>>> the check_view_pods_permission function using curl without --no-proxy. As
>>> far as I can tell this doesn't affect anything.
>>>
>>> So what do I need to look for to confirm that the second instance joined
>>> the cluster correctly? I am concerned that the proxy might be getting in
>>> the way somewhere else.
>>>
>>> Thanks
>>>
>>> Lionel
>>>
>>>
>>>
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>>
>>>
>>> --
>>> *Frédéric Giloux*
>>> Senior Middleware Consultant
>>>
>>> Red Hat GmbH
>>> MesseTurm, Friedrich-Ebert-Anlage 49, 60308 Frankfurt am Main
>>>
>>> Mobile: +49 (0) 174 1724661 
>>> E-Mail: fgil...@redhat.com, http://www.redhat.de/
>>>
>>> Delivering value year after year
>>> Red Hat ranks # 1 in value among software vendors
>>> http://www.redhat.com/promo/vendor/
>>>
>>> Freedom...Courage...Commitment...Accountability
>>> 
>>>
>>> Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
>>> Handelsregister: Amtsgericht München, HRB 153243
>>> Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham,
>>> Michael O'Neill
>>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: JBoss cluster

2016-11-17 Thread Lionel Orellana
But I can't tell if the second replica joined the cluster created by the
first.

I'm expecting to see "Number of cluster members: x" in the logs but it's
not showing in any of the two instances.

On 17 November 2016 at 22:55, Lionel Orellana <lione...@gmail.com> wrote:

> Thanks Frederick. I have done that.
>
> On Thu., 17 Nov. 2016 at 10:48 pm, Frederic Giloux <fgil...@redhat.com>
> wrote:
>
>> Hi Lionel,
>>
>> JBoss on OpenShift uses JGroups Kube_ping to discover the other members
>> of the cluster. This actually calls the Kubernetes REST API. Therefore you
>> need to have the proper rights allocated to your service account. More
>> information here: https://access.redhat.com/documentation/en/red-hat-
>> xpaas/0/single/red-hat-xpaas-eap-image/#clustering
>>
>> Best Regards,
>>
>> Frédéric
>>
>>
>> On Thu, Nov 17, 2016 at 11:58 AM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I'm trying to run Jboss cluster using the eap64-basic-s2i v1.3.2 template
>> on Origin 1.3.
>>
>> The application built and deployed fined. The second one started fine but
>> I can't tell if it joined the existing cluster. I was expecting to see an
>> output along the lines of "number of members in the cluster: 2" which I
>> have seen in the past with Jboss.
>>
>> There is a warning at the begining of the startup logs:
>>
>> "WARNING: Service account unable to test permissions to view pods in
>> kubernetes (HTTP 000). Clustering will be unavailable. Please refer to the
>> documentation for configuration."
>>
>> But looking at the ha.sh launch script this is just
>> the check_view_pods_permission function using curl without --no-proxy. As
>> far as I can tell this doesn't affect anything.
>>
>> So what do I need to look for to confirm that the second instance joined
>> the cluster correctly? I am concerned that the proxy might be getting in
>> the way somewhere else.
>>
>> Thanks
>>
>> Lionel
>>
>>
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>>
>>
>> --
>> *Frédéric Giloux*
>> Senior Middleware Consultant
>>
>> Red Hat GmbH
>> MesseTurm, Friedrich-Ebert-Anlage 49, 60308 Frankfurt am Main
>>
>> Mobile: +49 (0) 174 1724661 
>> E-Mail: fgil...@redhat.com, http://www.redhat.de/
>>
>> Delivering value year after year
>> Red Hat ranks # 1 in value among software vendors
>> http://www.redhat.com/promo/vendor/
>>
>> Freedom...Courage...Commitment...Accountability
>> 
>> Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
>> Handelsregister: Amtsgericht München, HRB 153243
>> Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham,
>> Michael O'Neill
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: JBoss cluster

2016-11-17 Thread Lionel Orellana
Thanks Frederick. I have done that.
On Thu., 17 Nov. 2016 at 10:48 pm, Frederic Giloux <fgil...@redhat.com>
wrote:

> Hi Lionel,
>
> JBoss on OpenShift uses JGroups Kube_ping to discover the other members of
> the cluster. This actually calls the Kubernetes REST API. Therefore you
> need to have the proper rights allocated to your service account. More
> information here:
> https://access.redhat.com/documentation/en/red-hat-xpaas/0/single/red-hat-xpaas-eap-image/#clustering
>
> Best Regards,
>
> Frédéric
>
>
> On Thu, Nov 17, 2016 at 11:58 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> Hi,
>
> I'm trying to run Jboss cluster using the eap64-basic-s2i v1.3.2 template
> on Origin 1.3.
>
> The application built and deployed fined. The second one started fine but
> I can't tell if it joined the existing cluster. I was expecting to see an
> output along the lines of "number of members in the cluster: 2" which I
> have seen in the past with Jboss.
>
> There is a warning at the begining of the startup logs:
>
> "WARNING: Service account unable to test permissions to view pods in
> kubernetes (HTTP 000). Clustering will be unavailable. Please refer to the
> documentation for configuration."
>
> But looking at the ha.sh launch script this is just
> the check_view_pods_permission function using curl without --no-proxy. As
> far as I can tell this doesn't affect anything.
>
> So what do I need to look for to confirm that the second instance joined
> the cluster correctly? I am concerned that the proxy might be getting in
> the way somewhere else.
>
> Thanks
>
> Lionel
>
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
>
>
> --
> *Frédéric Giloux*
> Senior Middleware Consultant
>
> Red Hat GmbH
> MesseTurm, Friedrich-Ebert-Anlage 49, 60308 Frankfurt am Main
>
> Mobile: +49 (0) 174 1724661 
> E-Mail: fgil...@redhat.com, http://www.redhat.de/
>
> Delivering value year after year
> Red Hat ranks # 1 in value among software vendors
> http://www.redhat.com/promo/vendor/
>
> Freedom...Courage...Commitment...Accountability
> 
> Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243
> Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham, Michael
> O'Neill
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


JBoss cluster

2016-11-17 Thread Lionel Orellana
Hi,

I'm trying to run Jboss cluster using the eap64-basic-s2i v1.3.2 template
on Origin 1.3.

The application built and deployed fined. The second one started fine but I
can't tell if it joined the existing cluster. I was expecting to see an
output along the lines of "number of members in the cluster: 2" which I
have seen in the past with Jboss.

There is a warning at the begining of the startup logs:

"WARNING: Service account unable to test permissions to view pods in
kubernetes (HTTP 000). Clustering will be unavailable. Please refer to the
documentation for configuration."

But looking at the ha.sh launch script this is just
the check_view_pods_permission function using curl without --no-proxy. As
far as I can tell this doesn't affect anything.

So what do I need to look for to confirm that the second instance joined
the cluster correctly? I am concerned that the proxy might be getting in
the way somewhere else.

Thanks

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


Re: Container PermGen expcetion kills entire node

2016-11-06 Thread Lionel Orellana
I don't.

openshift v1.3.0
docker v1.10.3

On 7 November 2016 at 09:57, Clayton Coleman <ccole...@redhat.com> wrote:

> Do you have resource limits defined on your Jenkins jobs containers?
> What version of OpenShift and Docker?
>
> > On Nov 6, 2016, at 2:23 PM, Lionel Orellana <lione...@gmail.com> wrote:
> >
> > Hi,
> >
> > A Jenkins job running on Openshift generated a PermGen expcetion.  I ran
> the job a couple more times to see if it would pass. I then realised that
> my two nodes had completely crashed. (i.e. I can't even login to the hosts,
> they have to be forcibly rebooted).
> >
> > Leaving aside the reason for the PermGen error, it's worrying that an
> exception inside a container could kill the entire node like that. And
> then, as the container is re-deployed to another node, it kills that one
> too. The entire cluster can be brought down by a naughty Jenkins job.
> >
> > How do I protect my cluster against this?
> >
> > Thanks
> >
> > Lionel.
> > ___
> > users mailing list
> > users@lists.openshift.redhat.com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Container PermGen expcetion kills entire node

2016-11-06 Thread Lionel Orellana
Hi,

A Jenkins job running on Openshift generated a PermGen expcetion.  I ran
the job a couple more times to see if it would pass. I then realised that
my two nodes had completely crashed. (i.e. I can't even login to the hosts,
they have to be forcibly rebooted).

Leaving aside the reason for the PermGen error, it's worrying that an
exception inside a container could kill the entire node like that. And
then, as the container is re-deployed to another node, it kills that one
too. The entire cluster can be brought down by a naughty Jenkins job.

How do I protect my cluster against this?

Thanks

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


JBoss EAP xPAAS - Oracle JDK

2016-11-02 Thread Lionel Orellana
Hi,

Are there any plans to include other JDK's in the JBoss EAP xPAAS images?
We run all our apps with Oracle JDK at the moment. Changing JDK's is not
something we want to do as part of a migration to Openshift. I can extend
your image and add Oracle's jdk but this is something others probably have
requested?

Thanks

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


Re: prune images error - 503

2016-10-25 Thread Lionel Orellana
It might be trying to go through the proxy.

>From the master this works.

curl -v --noproxy 172.19.38.253 http://172.19.38.253:5000/healthz

On 26 October 2016 at 09:04, Lionel Orellana <lione...@gmail.com> wrote:

> Hi Maciej
>
> Here's what I got from the prune logs.
>
> I1026 08:54:32.200913   20095 prune.go:794] Using registry:
> 172.19.38.253:5000
> I1026 08:54:32.200938   20095 prune.go:181] Trying https for
> 172.19.38.253:5000
> I1026 08:54:32.200995   20095 round_trippers.go:296] GET
> https://172.19.38.253:5000/healthz
> I1026 08:54:32.201010   20095 round_trippers.go:303] Request Headers:
> I1026 08:54:32.201021   20095 round_trippers.go:306] Authorization:
> Basic dW51c2VkOk53cmwtZ1FkM0x3Vm9CQU9hai1VdnZkTkljWG1NQ2QwRUN3UFVIN1c1LU0=
> I1026 08:55:32.483709   20095 round_trippers.go:321] Response Status:  in
> 60282 milliseconds
> I1026 08:55:32.483838   20095 prune.go:186] Error with https for
> 172.19.38.253:5000: Get https://172.19.38.253:5000/healthz: Service
> Unavailable
> I1026 08:55:32.483878   20095 prune.go:181] Trying http for
> 172.19.38.253:5000
> I1026 08:55:32.483939   20095 round_trippers.go:296] GET
> http://172.19.38.253:5000/healthz
> I1026 08:55:32.483961   20095 round_trippers.go:303] Request Headers:
> I1026 08:55:32.483974   20095 round_trippers.go:306] Authorization:
> Basic dW51c2VkOk53cmwtZ1FkM0x3Vm9CQU9hai1VdnZkTkljWG1NQ2QwRUN3UFVIN1c1LU0=
> I1026 08:56:35.078825   20095 round_trippers.go:321] Response Status: 503
> Service Unavailable in 62594 milliseconds
> I1026 08:56:35.078925   20095 prune.go:186] Error with http for
> 172.19.38.253:5000: unexpected status code 503
> F1026 08:56:35.079066   20095 helpers.go:110] error: error communicating
> with registry: unexpected status code 503
> -bash-4.2$
>
>
> The address of the registry is fine. The registry is insecure.
>
> On the registry logs the following came up. Not sure if it's related to
> the prune but it happened at the very same time.
>
> time="2016-10-25T21:56:37.829909567Z" level=error msg="error authorizing
> context: authorization header required" go.version=go1.6.3
> http.request.host="172.19.38.253:5000" 
> http.request.id=7df9debf-45eb-48fa-ae07-57a09de9b3b4
> http.request.method=GET http.request.remoteaddr="172.19.39.129:56350"
> http.request.uri="/v2/" http.request.useragent="docker/1.10.3 go/go1.6.2
> git-commit/2a93377-unsupported kernel/3.10.0-327.28.3.el7.x86_64 os/linux
> arch/amd64" instance.id=9e99450d-8197-4cce-ab17-1cf256d32a7c
> 172.19.39.129 - - [25/Oct/2016:21:56:37 +] "GET
> /openshift/token?account=serviceaccount=repository%3Atransaction-
> authority-lite%2Ftransaction-auth-lite%3Apull HTTP/1.1" 200 1823 ""
> "docker/1.10.3 go/go1.6.2 git-commit/2a93377-unsupported
> kernel/3.10.0-327.28.3.el7.x86_64 os/linux arch/amd64"
>
> time="2016-10-25T21:56:37.841655976Z" level=info msg="response completed"
> go.version=go1.6.3 http.request.host="172.19.38.253:5000" http.request.id
> =213f9613-c430-4386-bef2-cb67a7069f52 http.request.method=GET
> http.request.remoteaddr="172.19.39.129:56352"
> http.request.uri="/openshift/token?account=serviceaccount&
> scope=repository%3Atransaction-authority-lite%2Ftransaction-auth-lite%3Apull"
> http.request.useragent="docker/1.10.3 go/go1.6.2
> git-commit/2a93377-unsupported kernel/3.10.0-327.28.3.el7.x86_64 os/linux
> arch/amd64" http.response.contenttype="application/json"
> http.response.duration=6.642711ms http.response.status=200
> http.response.written=1823 instance.id=9e99450d-8197-
> 4cce-ab17-1cf256d32a7c
>
> time="2016-10-25T21:56:37.844393921Z" level=debug msg="authorizing
> request" go.version=go1.6.3 http.request.host="172.19.38.253:5000"
> http.request.id=fdcf1a81-7b93-4981-a957-7417386cf7de
> http.request.method=GET http.request.remoteaddr="172.19.39.129:56354"
> http.request.uri="/v2/transaction-authority-lite/transaction-auth-lite/
> manifests/sha256:591f586760735ddf513b8bad2f98aa
> a77d079050d6f0bd392eb4b93d6aa3e21b" http.request.useragent="docker/1.10.3
> go/go1.6.2 git-commit/2a93377-unsupported kernel/3.10.0-327.28.3.el7.x86_64
> os/linux arch/amd64" instance.id=9e99450d-8197-4cce-ab17-1cf256d32a7c
> vars.name="transaction-authority-lite/transaction-auth-lite"
> vars.reference="sha256:591f586760735ddf513b8bad2f98aa
> a77d079050d6f0bd392eb4b93d6aa3e21b"
>
> time="2016-10-25T21:56:37.844554174Z" level=debug msg="Origin auth:
> checking for access to 
> repository:transaction-authority-lite/transaction-auth-lite:pull"

Re: RHEL image

2016-10-19 Thread Lionel Orellana
Thanks Daniel.

That and a handy version.txt file in the EAP images will do.

sudo docker run -it jboss-eap-6/eap64-openshift:1.4-13 cat
/opt/eap/version.txt

On 20 October 2016 at 06:28, Daniel McPherson <dmcph...@redhat.com> wrote:

> sudo docker run -it rhel7: cat /etc/redhat-release
>
>
>
> On Tue, Oct 18, 2016 at 11:27 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> I suppose I can do this but what version of EAP (and RHEL) does each tag
>> map to?
>>
>> https://registry.access.redhat.com/v1/repositories/jboss-
>> eap-6/eap64-openshift/tags
>>
>> On 19 October 2016 at 14:19, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> Also, how do I see what tags are available for those images in the
>>> redhat registry?
>>>
>>> On 19 October 2016 at 12:15, Lionel Orellana <lione...@gmail.com> wrote:
>>>
>>>> Thanks Jonathan. Should have tried that.
>>>>
>>>> At the risk of asking another silly question, is there a way to easily
>>>> know what version of RHEL is an EAP image built on?
>>>> e.g. jboss-eap-6/eap64-openshift
>>>>
>>>> On 19 October 2016 at 12:03, Jonathan Yu <jaw...@redhat.com> wrote:
>>>>
>>>>> Hi Lionel,
>>>>>
>>>>> On Tue, Oct 18, 2016 at 5:49 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Is there an officially supported image of RHEL? I see all the xPaaS
>>>>>> images in the customer portal but nothing about a plain RHEL image like
>>>>>> there is for Centos.
>>>>>>
>>>>>
>>>>> Yes, there is: https://access.redhat.com/sear
>>>>> ch/#/container-images?q=rhel=1=relevant=12=
>>>>> any=ImageRepository
>>>>>
>>>>> On a RHEL system you should be able to do: "docker pull rhel7"
>>>>>
>>>>> This is the image that other Red Hat-supported images are built on.
>>>>>
>>>>> For example:
>>>>>
>>>>> official s2i-nodejs-container
>>>>> <https://github.com/sclorg/s2i-nodejs-container/blob/master/4/Dockerfile.rhel7>
>>>>> is FROM rhscl/s2i-base-rhel7
>>>>> <https://github.com/sclorg/s2i-base-container/blob/master/Dockerfile.rhel7>
>>>>> which is FROM rhel7.2 (see the access.redhat.com search above)
>>>>>
>>>>
>>>>
>>>
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: RHEL image

2016-10-18 Thread Lionel Orellana
I suppose I can do this but what version of EAP (and RHEL) does each tag
map to?

https://registry.access.redhat.com/v1/repositories/jboss-eap-6/eap64-openshift/tags

On 19 October 2016 at 14:19, Lionel Orellana <lione...@gmail.com> wrote:

> Also, how do I see what tags are available for those images in the redhat
> registry?
>
> On 19 October 2016 at 12:15, Lionel Orellana <lione...@gmail.com> wrote:
>
>> Thanks Jonathan. Should have tried that.
>>
>> At the risk of asking another silly question, is there a way to easily
>> know what version of RHEL is an EAP image built on?
>> e.g. jboss-eap-6/eap64-openshift
>>
>> On 19 October 2016 at 12:03, Jonathan Yu <jaw...@redhat.com> wrote:
>>
>>> Hi Lionel,
>>>
>>> On Tue, Oct 18, 2016 at 5:49 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> Is there an officially supported image of RHEL? I see all the xPaaS
>>>> images in the customer portal but nothing about a plain RHEL image like
>>>> there is for Centos.
>>>>
>>>
>>> Yes, there is: https://access.redhat.com/sear
>>> ch/#/container-images?q=rhel=1=relevant=12=
>>> any=ImageRepository
>>>
>>> On a RHEL system you should be able to do: "docker pull rhel7"
>>>
>>> This is the image that other Red Hat-supported images are built on.
>>>
>>> For example:
>>>
>>> official s2i-nodejs-container
>>> <https://github.com/sclorg/s2i-nodejs-container/blob/master/4/Dockerfile.rhel7>
>>> is FROM rhscl/s2i-base-rhel7
>>> <https://github.com/sclorg/s2i-base-container/blob/master/Dockerfile.rhel7>
>>> which is FROM rhel7.2 (see the access.redhat.com search above)
>>>
>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: RHEL image

2016-10-18 Thread Lionel Orellana
Also, how do I see what tags are available for those images in the redhat
registry?

On 19 October 2016 at 12:15, Lionel Orellana <lione...@gmail.com> wrote:

> Thanks Jonathan. Should have tried that.
>
> At the risk of asking another silly question, is there a way to easily
> know what version of RHEL is an EAP image built on? e.g. jboss-eap-6/eap64-
> openshift
>
> On 19 October 2016 at 12:03, Jonathan Yu <jaw...@redhat.com> wrote:
>
>> Hi Lionel,
>>
>> On Tue, Oct 18, 2016 at 5:49 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> Is there an officially supported image of RHEL? I see all the xPaaS
>>> images in the customer portal but nothing about a plain RHEL image like
>>> there is for Centos.
>>>
>>
>> Yes, there is: https://access.redhat.com/sear
>> ch/#/container-images?q=rhel=1=relevant=12&
>> srch=any=ImageRepository
>>
>> On a RHEL system you should be able to do: "docker pull rhel7"
>>
>> This is the image that other Red Hat-supported images are built on.
>>
>> For example:
>>
>> official s2i-nodejs-container
>> <https://github.com/sclorg/s2i-nodejs-container/blob/master/4/Dockerfile.rhel7>
>> is FROM rhscl/s2i-base-rhel7
>> <https://github.com/sclorg/s2i-base-container/blob/master/Dockerfile.rhel7>
>> which is FROM rhel7.2 (see the access.redhat.com search above)
>>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: RHEL image

2016-10-18 Thread Lionel Orellana
Thanks Jonathan. Should have tried that.

At the risk of asking another silly question, is there a way to easily know
what version of RHEL is an EAP image built on?
e.g. jboss-eap-6/eap64-openshift

On 19 October 2016 at 12:03, Jonathan Yu <jaw...@redhat.com> wrote:

> Hi Lionel,
>
> On Tue, Oct 18, 2016 at 5:49 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hi
>>
>> Is there an officially supported image of RHEL? I see all the xPaaS
>> images in the customer portal but nothing about a plain RHEL image like
>> there is for Centos.
>>
>
> Yes, there is: https://access.redhat.com/search/#/container-images?q=
> rhel=1=relevant=12=any=ImageRepository
>
> On a RHEL system you should be able to do: "docker pull rhel7"
>
> This is the image that other Red Hat-supported images are built on.
>
> For example:
>
> official s2i-nodejs-container
> <https://github.com/sclorg/s2i-nodejs-container/blob/master/4/Dockerfile.rhel7>
> is FROM rhscl/s2i-base-rhel7
> <https://github.com/sclorg/s2i-base-container/blob/master/Dockerfile.rhel7>
> which is FROM rhel7.2 (see the access.redhat.com search above)
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


RHEL image

2016-10-18 Thread Lionel Orellana
Hi

Is there an officially supported image of RHEL? I see all the xPaaS images
in the customer portal but nothing about a plain RHEL image like there is
for Centos.

Thanks

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


Re: jboss-eap64-openshift quickstart maven proxy

2016-10-13 Thread Lionel Orellana
The Wildfly quickstarts work out of the box. Are the Wildfly and JBoss
builder images completely different? What's the relationship
between jboss-eap-6/eap64-openshift and openshift/wildfly-100-centos7?

On 14 October 2016 at 11:00, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Thu, Oct 13, 2016 at 6:14 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Thanks Jim.
>>
>> It worked by setting
>>
>> HTTP_PROXY_HOST=proxy.server.name
>>
>> and
>>
>> HTTP_PROXY_PORT=port
>>
>>
>> Are these supposed to be set globally by the Ansible scripts? I have
>> openshift_http_proxy, openshift_https_proxy, openshift_no_proxy and
>> openshift_generate_no_proxy_hosts in my inventory file.
>>
>
> ​no, unfortunately those values are very specific to those particular
> images.  That said, we have an open issue to have those images updated to
> respect the more standard proxy env variables.
> ​
>
>
>
>>
>> On 13 October 2016 at 19:25, Jim Minter <jmin...@redhat.com> wrote:
>>
>>> Hi Lionel,
>>>
>>> It should be a case of setting the HTTP_PROXY_HOST environment
>>> variable.  (I'm not sure why it's not just plain HTTP_PROXY - sorry).  See
>>> [1].
>>>
>>> Also note that you can predefine this and other environment variables
>>> used at build time globally across the cluster if you like [2].
>>>
>>> [1] https://access.redhat.com/documentation/en/red-hat-xpaas/0/s
>>> ingle/red-hat-xpaas-eap-image/#environment_variables_3
>>> [2] https://docs.openshift.com/container-platform/3.3/install_co
>>> nfig/build_defaults_overrides.html
>>>
>>> Cheers,
>>>
>>> Jim
>>>
>>> --
>>> Jim Minter
>>> Principal Software Engineer, Red Hat UK
>>>
>>>
>>> On 13/10/16 08:27, Lionel Orellana wrote:
>>>
>>>> Hi
>>>>
>>>> I'm trying to run the jboss-eap64-openshift quickstart but the build is
>>>> failing to download from maven central.
>>>>
>>>> [ERROR] Non-resolvable import POM: Could not transfer artifact
>>>> org.jboss.bom.eap:jboss-javaee-6.0-with-tools:pom:6.4.0.GA
>>>> <http://6.4.0.GA> from/to central
>>>> (https://repo1.maven.org/maven2):Connection to https://repo1.maven.org
>>>> <https://repo1.maven.org/>refused @ line 71, column 25
>>>>
>>>> I had no problems with the Wildfly quickstarts.
>>>>
>>>> I tried setting proxyHost and proxyPort in MAVEN_OPTS but that did
>>>> nothing.
>>>>
>>>> Do I really have to clone the repo and modify the maven settings.xml
>>>> file to run the quickstart? How come Wildfly works?
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: jboss-eap64-openshift quickstart maven proxy

2016-10-13 Thread Lionel Orellana
Thanks Jim.

It worked by setting

HTTP_PROXY_HOST=proxy.server.name

and

HTTP_PROXY_PORT=port


Are these supposed to be set globally by the Ansible scripts? I have
openshift_http_proxy, openshift_https_proxy, openshift_no_proxy and
openshift_generate_no_proxy_hosts in my inventory file.

On 13 October 2016 at 19:25, Jim Minter <jmin...@redhat.com> wrote:

> Hi Lionel,
>
> It should be a case of setting the HTTP_PROXY_HOST environment variable.
> (I'm not sure why it's not just plain HTTP_PROXY - sorry).  See [1].
>
> Also note that you can predefine this and other environment variables used
> at build time globally across the cluster if you like [2].
>
> [1] https://access.redhat.com/documentation/en/red-hat-xpaas/0/
> single/red-hat-xpaas-eap-image/#environment_variables_3
> [2] https://docs.openshift.com/container-platform/3.3/install_
> config/build_defaults_overrides.html
>
> Cheers,
>
> Jim
>
> --
> Jim Minter
> Principal Software Engineer, Red Hat UK
>
>
> On 13/10/16 08:27, Lionel Orellana wrote:
>
>> Hi
>>
>> I'm trying to run the jboss-eap64-openshift quickstart but the build is
>> failing to download from maven central.
>>
>> [ERROR] Non-resolvable import POM: Could not transfer artifact
>> org.jboss.bom.eap:jboss-javaee-6.0-with-tools:pom:6.4.0.GA
>> <http://6.4.0.GA> from/to central
>> (https://repo1.maven.org/maven2):Connection to https://repo1.maven.org
>> <https://repo1.maven.org/>refused @ line 71, column 25
>>
>> I had no problems with the Wildfly quickstarts.
>>
>> I tried setting proxyHost and proxyPort in MAVEN_OPTS but that did
>> nothing.
>>
>> Do I really have to clone the repo and modify the maven settings.xml
>> file to run the quickstart? How come Wildfly works?
>>
>> Thanks
>>
>>
>>
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Promoting deploymentconfigs etc. from dev->testing->production

2016-10-12 Thread Lionel Orellana
One of the biggest problems we have with our current infrastructure/process
(and which we are trying to address with Openshift) is multiple teams
fighting for shared environments (test, uat, stage, prod). This led to a
terrible "deployment train" anti-pattern with 4 big releases a year to
promote apps through the environments. If you missed the train in dev you
have to wait for the next one.

Anyway, maybe an Openshift project per app is too extreme but we want more
than one dev, test and stage to give different teams their own path to
prod.

On 13 October 2016 at 14:20, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Wed, Oct 12, 2016 at 10:04 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> May I ask in relation to this, how do you define an "environment" at the
>> moment? My first instinct was to create a project for one app and configure
>> different service/deployments referencing different image tags (e.g. dev,
>> test, etc). Given that all services within a project are automatically
>> injected env vars to find other services, this doesn't really work. So it
>> seems I need a project per app per environment. And then a single PROD
>> project? That's an awful amount of projects. Is that a common
>> current practice ?
>>
>
> one project per "environment" (dev, test, stage, prod) is certainly one of
> our recommendations (a cluster per environment is another valid option).
>
> not sure why you need a project per app, however.  (you may have your
> reasons, but it's reasonable to run multiple apps in a single project as
> well)
>
>
> ​
>
>
>
>>
>> Thanks
>>
>> On 6 September 2016 at 01:21, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Mon, Sep 5, 2016 at 8:59 AM, Pieter Nagel <pie...@lautus.net> wrote:
>>>
>>>> All documentation I've seen so far shows how to build a Continuous
>>>> Delivery pipeline by tagging a specific image for testing/deployment.
>>>>
>>>> But apps consist of more than single images, they also consist of
>>>> surrounding deployment configs, services etc. that combine all together
>>>> into a working system.
>>>>
>>>> How does one manage the promotion of the entire set of these through
>>>> the entire CD pipeline?
>>>>
>>>> In effect, I want to take a specific deploymentconfig from which a
>>>> specific "known good" deployment in development was created, and clone that
>>>> into testing -> production, along with related services and routes, except
>>>> that image references should be rewritten to reuse the exact same "known
>>>> good" images.
>>>>
>>>
>>> ​Yes this is a space we are actively investigating.  As you note, there
>>> are two parts to promotion, one being the promoted "content" (images,
>>> normally) and the other being the promoted "configuration".  Today for
>>> promoting configuration the basic flow would be to do an "oc export" from
>>> one environment and then "oc apply" those resources to your next
>>> environment (possibly with some manual transformation of the resources in
>>> between).  But Gabe and Justin from my team (on CC) are actively working on
>>> how we make that story better.  Keep an eye on these trello cards:
>>>
>>> https://trello.com/c/HlQpE52w/848-8-provide-example-of-promo
>>> ting-application-between-datacenters-projects-evg
>>> https://trello.com/c/Mvuy5Afi/993-8-define-an-environment-resource-r-d
>>>
>>> The first one is intended to develop some documentation that users can
>>> use today to manually go through promotion flows via oc export/apply/etc,
>>> but with more prescriptive direction.  The second represents our longer
>>> term vision to make promotion between environments a first class feature of
>>> OpenShift, with specific tools for accomplishing it.
>>>
>>> ​I'm sure Gabe and Justin would be very interested to hear more about
>>> your specific use case in order to ensure it is covered as they are
>>> thinking about this.
>>>
>>>
>>>
>>>
>>>>
>>>> Is there a better procedure than "check if the definition of the
>>>> deploymentconfig changed during the last cycle, and if so, `oc apply` the
>>>> relevant changes to the testing/production projects before tagging the
>>>> image"?
>>>>
>>>> --
>>>> Pieter Nagel
>>>> Lautus Solutions (Pty) Ltd
>>>> Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
>>>> 0832587540
>>>>
>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>> Ben Parees | OpenShift
>>>
>>>
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: External Oracle service

2016-10-11 Thread Lionel Orellana
So I got the external service and endpoint for my oracle database going. It
seems that within a project all services get environments variables to
locate all the other services. Can I restrict what services are able to see
my external database? In the mysql example that would be limiting who gets
the value of *EXTERNAL_MYSQL_SERVICE_SERVICE_HOST *injected.

On 11 October 2016 at 16:43, Lionel Orellana <lione...@gmail.com> wrote:

> Hello
>
> I've seen some articles on how to define an external service for mysql (
> https://docs.openshift.com/container-platform/3.3/dev_
> guide/integrating_external_services.html).
>
> Does the same method apply to an external Oracle database?
>
> I don't understand where the variable
> *EXTERNAL_MYSQL_SERVICE_SERVICE_HOST *comes from in the above link.
>
> If the app has environment variables like
>
> env:
>   -
> name: "MYSQL_USER"
> value: "${MYSQL_USER}"
>
> Where does the value of ${MYSQL_USER} come from?
>
> thanks
>
> Lionel.
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Node fails to start after system reboot

2016-10-10 Thread Lionel Orellana
Apparently we had run out of disk space on the node.

I couldn't recover from that even after clearing space and deleting
/var/lib/docker.  Had to throw away the node and start again. Wonder if
there was a better way of handling this.

On 10 October 2016 at 12:12, Lionel Orellana <lione...@gmail.com> wrote:

> Something broke docker.
>
> # docker run hello-world
> docker: Error response from daemon: devicemapper: Error running
> deviceCreate (createSnapDevice) dm_task_run failed.
> See '/usr/bin/docker-current run --help'.
> #
>
> # docker info
> Containers: 1
>  Running: 0
>  Paused: 0
>  Stopped: 1
> Images: 283
> Server Version: 1.10.3
> Storage Driver: devicemapper
>  Pool Name: docker-0:38-148510880-pool
>  Pool Blocksize: 65.54 kB
>  Base Device Size: 10.74 GB
>  Backing Filesystem: xfs
>  Data file: /dev/loop0
>  Metadata file: /dev/loop1
>  Data Space Used: 38.19 GB
>  Data Space Total: 107.4 GB
>  Data Space Available: 16.89 GB
>  Metadata Space Used: 45.18 MB
>  Metadata Space Total: 2.147 GB
>  Metadata Space Available: 2.102 GB
>  Udev Sync Supported: true
>  Deferred Removal Enabled: false
>  Deferred Deletion Enabled: false
>  Deferred Deleted Device Count: 0
>  Data loop file: /var/lib/docker/devicemapper/devicemapper/data
>  WARNING: Usage of loopback devices is strongly discouraged for production
> use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt
> dm.no_warn_on_loop_devices=true` to suppress this warning.
>  Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
>  Library Version: 1.02.107-RHEL7 (2016-06-09)
> Execution Driver: native-0.2
> Logging Driver: json-file
> Plugins:
>  Volume: local
>  Network: bridge null host
> Kernel Version: 3.10.0-327.28.3.el7.x86_64
> Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
> OSType: linux
> Architecture: x86_64
> Number of Docker Hooks: 2
> CPUs: 1
> Total Memory: 3.703 GiB
> Name: xx
> ID: S7TX:CAUS:656Z:TLJN:IS2F:CICD:RISE:7N76:MRSA:HUBP:MINL:WU7M
> Debug mode (server): true
>  File Descriptors: 16
>  Goroutines: 24
>  System Time: 2016-10-10T12:11:00.561344233+11:00
>  EventsListeners: 0
>  Init SHA1: 1f87ef7fa7fd7401b9aa61ca3a3e096b4fd2228e
>  Init Path:
>  Docker Root Dir: /var/lib/docker
> WARNING: bridge-nf-call-iptables is disabled
> WARNING: bridge-nf-call-ip6tables is disabled
> Registries: docker.io (secure)
>
>
>
> On 10 October 2016 at 10:36, Lionel Orellana <lione...@gmail.com> wrote:
>
>> I deleted all containers with
>>
>> docker rm -v $(docker ps -q -f status=exited)
>>
>> The openvswitch service continous to fail claiming the name already
>> exists.
>>
>> Oct 10 10:30:28 poc-docker02.aipo.gov.au openvswitch[17706]: docker:
>> Error response from daemon: Conflict. The name "/openvswitch" is already in
>> use by container b9a94ed6a5885c5b02f9fe456b27e4
>> 09c4ce2732a3e7be1bce19d8d69f397d2d. You have to remove (or rename) that
>> container to be able to reuse that name..
>> Oct 10 10:30:28 poc-docker02.aipo.gov.au openvswitch[17706]: See
>> '/usr/bin/docker-current run --help'.
>> --
>>
>> # docker ps -a
>> CONTAINER IDIMAGE   COMMAND CREATED
>>   STATUS  PORTS   NAMES
>> #
>>
>>
>>
>> On 10 October 2016 at 09:44, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm getting this error on my nodes after the host has rebooted.
>>>
>>> Oct 10 09:22:13 poc-docker02.aipo.gov.au systemd[1]: Job
>>> origin-node.service/start failed with result 'dependency'.
>>> Oct 10 09:22:23 poc-docker02.aipo.gov.au systemd[1]: Dependency failed
>>> for origin-node.service.
>>> -- Subject: Unit origin-node.service has failed
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> --
>>> -- Unit origin-node.service has failed.
>>> --
>>> -- The result is dependency.
>>>
>>> No container is running. (i.e. docker ps returns nothing but -a does).
>>>
>>> It seems to be failing to create openvswitch because it already exists?
>>> Should I delete old containers? Any advice on getting a clean system
>>> reboot?
>>>
>>> $journalct -xe
>>>
>>> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
>>> time="2016-10-10T09:37:47.353549643+11:00" level=debug msg="Calling
>>> POST /v1.22/containers/create"
>>> Oct 10 09:37:47 poc-docker0

External Oracle service

2016-10-10 Thread Lionel Orellana
Hello

I've seen some articles on how to define an external service for mysql (
https://docs.openshift.com/container-platform/3.3/dev_guide/integrating_external_services.html
).

Does the same method apply to an external Oracle database?

I don't understand where the variable
*EXTERNAL_MYSQL_SERVICE_SERVICE_HOST *comes
from in the above link.

If the app has environment variables like

env:
  -
name: "MYSQL_USER"
value: "${MYSQL_USER}"

Where does the value of ${MYSQL_USER} come from?

thanks

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


Re: Node fails to start after system reboot

2016-10-09 Thread Lionel Orellana
Something broke docker.

# docker run hello-world
docker: Error response from daemon: devicemapper: Error running
deviceCreate (createSnapDevice) dm_task_run failed.
See '/usr/bin/docker-current run --help'.
#

# docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 283
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker-0:38-148510880-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 38.19 GB
 Data Space Total: 107.4 GB
 Data Space Available: 16.89 GB
 Metadata Space Used: 45.18 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.102 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production
use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt
dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.10.0-327.28.3.el7.x86_64
Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 1
Total Memory: 3.703 GiB
Name: xx
ID: S7TX:CAUS:656Z:TLJN:IS2F:CICD:RISE:7N76:MRSA:HUBP:MINL:WU7M
Debug mode (server): true
 File Descriptors: 16
 Goroutines: 24
 System Time: 2016-10-10T12:11:00.561344233+11:00
 EventsListeners: 0
 Init SHA1: 1f87ef7fa7fd7401b9aa61ca3a3e096b4fd2228e
 Init Path:
 Docker Root Dir: /var/lib/docker
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Registries: docker.io (secure)



On 10 October 2016 at 10:36, Lionel Orellana <lione...@gmail.com> wrote:

> I deleted all containers with
>
> docker rm -v $(docker ps -q -f status=exited)
>
> The openvswitch service continous to fail claiming the name already
> exists.
>
> Oct 10 10:30:28 poc-docker02.aipo.gov.au openvswitch[17706]: docker:
> Error response from daemon: Conflict. The name "/openvswitch" is already in
> use by container b9a94ed6a5885c5b02f9fe456b27e4
> 09c4ce2732a3e7be1bce19d8d69f397d2d. You have to remove (or rename) that
> container to be able to reuse that name..
> Oct 10 10:30:28 poc-docker02.aipo.gov.au openvswitch[17706]: See
> '/usr/bin/docker-current run --help'.
> --
>
> # docker ps -a
> CONTAINER IDIMAGE   COMMAND CREATED
>   STATUS  PORTS   NAMES
> #
>
>
>
> On 10 October 2016 at 09:44, Lionel Orellana <lione...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm getting this error on my nodes after the host has rebooted.
>>
>> Oct 10 09:22:13 poc-docker02.aipo.gov.au systemd[1]: Job
>> origin-node.service/start failed with result 'dependency'.
>> Oct 10 09:22:23 poc-docker02.aipo.gov.au systemd[1]: Dependency failed
>> for origin-node.service.
>> -- Subject: Unit origin-node.service has failed
>> -- Defined-By: systemd
>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> --
>> -- Unit origin-node.service has failed.
>> --
>> -- The result is dependency.
>>
>> No container is running. (i.e. docker ps returns nothing but -a does).
>>
>> It seems to be failing to create openvswitch because it already exists?
>> Should I delete old containers? Any advice on getting a clean system
>> reboot?
>>
>> $journalct -xe
>>
>> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
>> time="2016-10-10T09:37:47.353549643+11:00" level=debug msg="Calling POST
>> /v1.22/containers/create"
>> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
>> time="2016-10-10T09:37:47.353603207+11:00" level=debug msg="POST
>> /v1.22/containers/create?name=openvswitch"
>> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
>> time="2016-10-10T09:37:47.353898488+11:00" level=debug msg="form data:
>> {\"AttachStderr\":true,\"AttachStdin\":false,\"AttachStdout\
>> ":true,\"Cmd\":null,\"Domainname\":\"\",\"Entry
>> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
>> time="2016-10-10T09:37:47.354052936+11:00" level=info
>> msg="{Action=create, LoginUID=4294967295, PID=9878}"
>> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
>> time="2016-10-10T09:37:47.359950019+11:00" level=er

Re: Node fails to start after system reboot

2016-10-09 Thread Lionel Orellana
I deleted all containers with

docker rm -v $(docker ps -q -f status=exited)

The openvswitch service continous to fail claiming the name already exists.

Oct 10 10:30:28 poc-docker02.aipo.gov.au openvswitch[17706]: docker: Error
response from daemon: Conflict. The name "/openvswitch" is already in use
by container
b9a94ed6a5885c5b02f9fe456b27e409c4ce2732a3e7be1bce19d8d69f397d2d. You have
to remove (or rename) that container to be able to reuse that name..
Oct 10 10:30:28 poc-docker02.aipo.gov.au openvswitch[17706]: See
'/usr/bin/docker-current run --help'.
--

# docker ps -a
CONTAINER IDIMAGE   COMMAND CREATED
STATUS  PORTS   NAMES
#



On 10 October 2016 at 09:44, Lionel Orellana <lione...@gmail.com> wrote:

> Hi,
>
> I'm getting this error on my nodes after the host has rebooted.
>
> Oct 10 09:22:13 poc-docker02.aipo.gov.au systemd[1]: Job
> origin-node.service/start failed with result 'dependency'.
> Oct 10 09:22:23 poc-docker02.aipo.gov.au systemd[1]: Dependency failed
> for origin-node.service.
> -- Subject: Unit origin-node.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit origin-node.service has failed.
> --
> -- The result is dependency.
>
> No container is running. (i.e. docker ps returns nothing but -a does).
>
> It seems to be failing to create openvswitch because it already exists?
> Should I delete old containers? Any advice on getting a clean system
> reboot?
>
> $journalct -xe
>
> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
> time="2016-10-10T09:37:47.353549643+11:00" level=debug msg="Calling POST
> /v1.22/containers/create"
> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
> time="2016-10-10T09:37:47.353603207+11:00" level=debug msg="POST
> /v1.22/containers/create?name=openvswitch"
> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
> time="2016-10-10T09:37:47.353898488+11:00" level=debug msg="form data:
> {\"AttachStderr\":true,\"AttachStdin\":false,\"
> AttachStdout\":true,\"Cmd\":null,\"Domainname\":\"\",\"Entry
> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
> time="2016-10-10T09:37:47.354052936+11:00" level=info
> msg="{Action=create, LoginUID=4294967295, PID=9878}"
> Oct 10 09:37:47 poc-docker02.aipo.gov.au docker[7343]:
> time="2016-10-10T09:37:47.359950019+11:00" level=error msg="Handler for
> POST /v1.22/containers/create returned error: Conflict. The name
> \"/openvswitch\" is already in use by con
> Oct 10 09:37:47 poc-docker02.aipo.gov.au openvswitch[9878]: *docker:
> Error response from daemon: Conflict. The name "/openvswitch" is already in
> use by container *497532ea92a4e14782b96b15f2763d
> 3883d2843d5fdf473f720170756e4de815. You ha
> Oct 10 09:37:47 poc-docker02.aipo.gov.au openvswitch[9878]: See
> '/usr/bin/docker-current run --help'.
> Oct 10 09:37:47 poc-docker02.aipo.gov.au systemd[1]: openvswitch.service:
> main process exited, code=exited, status=125/n/a
> Oct 10 09:37:50 poc-docker02.aipo.gov.au polkitd[847]: Registered
> Authentication Agent for unix-process:9885:60099516 (system bus name
> :1.3589 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path
> /org/freedesktop/PolicyKit1/Au
> Oct 10 09:37:50 poc-docker02.aipo.gov.au systemd[1]: Cannot add
> dependency job for unit origin-master.service, ignoring: Unit
> origin-master.service failed to load: No such file or directory.
> Oct 10 09:37:50 poc-docker02.aipo.gov.au systemd[1]: Cannot add
> dependency job for unit origin-master.service, ignoring: Unit
> origin-master.service failed to load: No such file or directory.
> Oct 10 09:37:50 poc-docker02.aipo.gov.au systemd[1]: Started
> origin-node-dep.service.
>
>
> thanks
>
>
> Lionel
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Jenkins plugin - binary build

2016-10-05 Thread Lionel Orellana
Ok thanks Ben.

On 6 October 2016 at 13:01, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Wed, Oct 5, 2016 at 6:48 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Can you tag the Jenkins images with the Jenkins version you are using or
>> some other convention? I don't like using latest and getting unexpected
>> upgrades. How often do you upgrade the Jenkins version?
>>
>
> ​we upgrade it when we notice there's a new jenkins LTS available.  we
> don't have any current plans to tag it more specifically, we introduce new
> repos (eg jenkins-1-centos7 vs jenkins-2-centos7) when we make significant
> changes.  I'd recommend you re-tag it yourself if you want a guaranteed
> stable tag for the image.
>
> (Also if you're using imagestreams in openshift, you won't get a new
> version unless you explicitly re-import the imagestream).
> ​
>
>
>
>>
>> Thanks.
>>
>> On 6 October 2016 at 02:09, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Oct 5, 2016 6:59 AM, "Lionel Orellana" <lione...@gmail.com> wrote:
>>>
>>>> The Jenkins v2 image is not yet available in docker hub is it?
>>>>
>>>
>>> ​it wasn't, but it is now:  openshift/jenkins-2-centos7​
>>>
>>>
>>>
>>>>
>>>> On 5 October 2016 at 16:24, Lionel Orellana <lione...@gmail.com> wrote:
>>>>
>>>>> I wanted to use Jenkins v2 which you didn't have an image for. I see
>>>>> that there is one now. I'll have to consider if it's worth switching over.
>>>>>
>>>>> On 4 October 2016 at 09:54, Ben Parees <bpar...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 3, 2016 at 6:28 PM, Lionel Orellana <lione...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> No, I started with the image provided by the jenkins guys.
>>>>>>>
>>>>>>
>>>>>> ​I strongly suggest you use our image which includes the oc tooling
>>>>>> and, if instantiated from our template, will have all the correct
>>>>>> permissions for interacting with openshift.
>>>>>>
>>>>>> https://github.com/openshift/origin/tree/master/examples/jenkins
>>>>>> ​
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 30 September 2016 at 01:22, Ben Parees <bpar...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 29, 2016 at 12:05 AM, Lionel Orellana <
>>>>>>>> lione...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Ah I am running Jenkins inside a pod and invoking oc from there.
>>>>>>>>> Thanks for the tip.
>>>>>>>>>
>>>>>>>>> Before I can run oc I'm having to set KUBECONFIG to some location
>>>>>>>>> I know I can write to.
>>>>>>>>>
>>>>>>>>> Otherwise I get this error when running any oc command:
>>>>>>>>>
>>>>>>>>> error: KUBECONFIG is set to a file that cannot be created or
>>>>>>>>> modified: /.kube/config
>>>>>>>>> mkdir /.kube: permission denied
>>>>>>>>>
>>>>>>>>> To install the client I simply downloaded the tar, unpacked and
>>>>>>>>> created a sym link. Do I need any more setup or setting KUBECONFIG 
>>>>>>>>> every
>>>>>>>>> time is the way to go?
>>>>>>>>>
>>>>>>>>
>>>>>>>> ​are you using our jenkins image?  our image includes the oc
>>>>>>>> tooling.
>>>>>>>>
>>>>>>>> https://github.com/openshift/jenkins
>>>>>>>> ​
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28 September 2016 at 22:51, Cesar Wong <cew...@redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> You can always create a new role that o

Re: Jenkins plugin - binary build

2016-10-05 Thread Lionel Orellana
Can you tag the Jenkins images with the Jenkins version you are using or
some other convention? I don't like using latest and getting unexpected
upgrades. How often do you upgrade the Jenkins version?

Thanks.

On 6 October 2016 at 02:09, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Oct 5, 2016 6:59 AM, "Lionel Orellana" <lione...@gmail.com> wrote:
>
>> The Jenkins v2 image is not yet available in docker hub is it?
>>
>
> ​it wasn't, but it is now:  openshift/jenkins-2-centos7​
>
>
>
>>
>> On 5 October 2016 at 16:24, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> I wanted to use Jenkins v2 which you didn't have an image for. I see
>>> that there is one now. I'll have to consider if it's worth switching over.
>>>
>>> On 4 October 2016 at 09:54, Ben Parees <bpar...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 3, 2016 at 6:28 PM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>> No, I started with the image provided by the jenkins guys.
>>>>>
>>>>
>>>> ​I strongly suggest you use our image which includes the oc tooling
>>>> and, if instantiated from our template, will have all the correct
>>>> permissions for interacting with openshift.
>>>>
>>>> https://github.com/openshift/origin/tree/master/examples/jenkins
>>>> ​
>>>>
>>>>
>>>>
>>>>>
>>>>> On 30 September 2016 at 01:22, Ben Parees <bpar...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 29, 2016 at 12:05 AM, Lionel Orellana <lione...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Ah I am running Jenkins inside a pod and invoking oc from there.
>>>>>>> Thanks for the tip.
>>>>>>>
>>>>>>> Before I can run oc I'm having to set KUBECONFIG to some location I
>>>>>>> know I can write to.
>>>>>>>
>>>>>>> Otherwise I get this error when running any oc command:
>>>>>>>
>>>>>>> error: KUBECONFIG is set to a file that cannot be created or
>>>>>>> modified: /.kube/config
>>>>>>> mkdir /.kube: permission denied
>>>>>>>
>>>>>>> To install the client I simply downloaded the tar, unpacked and
>>>>>>> created a sym link. Do I need any more setup or setting KUBECONFIG every
>>>>>>> time is the way to go?
>>>>>>>
>>>>>>
>>>>>> ​are you using our jenkins image?  our image includes the oc tooling.
>>>>>>
>>>>>> https://github.com/openshift/jenkins
>>>>>> ​
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 28 September 2016 at 22:51, Cesar Wong <cew...@redhat.com> wrote:
>>>>>>>
>>>>>>>> You can always create a new role that only allows the actions that
>>>>>>>> you need to kick off a new build (create on builds and builds/source,  
>>>>>>>> read
>>>>>>>> on buildconfigs).
>>>>>>>>
>>>>>>>> Also, if you're running oc inside a pod within OpenShift, oc will
>>>>>>>> use the credentials of the service account used to run the pod. No 
>>>>>>>> need to
>>>>>>>> explicitly log in.
>>>>>>>>
>>>>>>>> On Sep 28, 2016, at 1:40 AM, Lionel Orellana <lione...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Adding the edit cluster role seems to work.
>>>>>>>>
>>>>>>>> oadm policy add-cluster-role-to-user edit
>>>>>>>> system:serviceaccount:jenkins:jenkins
>>>>>>>>
>>>>>>>> But is feels I'm giving it too much access. I tried with role
>>>>>>>> system:build-controller but that wasn't enough.
>>>>>>>>
>>>>>>>> On 28 September 2016 at 14:00, Lionel Orellana <lione...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thanks. Invoking oc will do.
>>

docker build-arg

2016-10-05 Thread Lionel Orellana
Hi All,

Is there a way to specify a build-arg to a docker build.

I have a Dockerfile with an ARG statement and I would like to run something
equivalent to

$docker build --build-arg ARG1=value ./build-dir

My docker buildconfig is setup and I can trigger new builds without the arg
as

$oc start-build  --from-dir=./build-dir

I tried using -e but got a warning:

WARNING: Specifying environment variables with binary builds is not
supported.

So is there a way to pass build-args or is it simply not supported?

Thanks

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


Re: Jenkins plugin - binary build

2016-10-04 Thread Lionel Orellana
I wanted to use Jenkins v2 which you didn't have an image for. I see that
there is one now. I'll have to consider if it's worth switching over.

On 4 October 2016 at 09:54, Ben Parees <bpar...@redhat.com> wrote:

>
>
> On Mon, Oct 3, 2016 at 6:28 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> No, I started with the image provided by the jenkins guys.
>>
>
> ​I strongly suggest you use our image which includes the oc tooling and,
> if instantiated from our template, will have all the correct permissions
> for interacting with openshift.
>
> https://github.com/openshift/origin/tree/master/examples/jenkins
> ​
>
>
>
>>
>> On 30 September 2016 at 01:22, Ben Parees <bpar...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 29, 2016 at 12:05 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Ah I am running Jenkins inside a pod and invoking oc from there. Thanks
>>>> for the tip.
>>>>
>>>> Before I can run oc I'm having to set KUBECONFIG to some location I
>>>> know I can write to.
>>>>
>>>> Otherwise I get this error when running any oc command:
>>>>
>>>> error: KUBECONFIG is set to a file that cannot be created or modified:
>>>> /.kube/config
>>>> mkdir /.kube: permission denied
>>>>
>>>> To install the client I simply downloaded the tar, unpacked and created
>>>> a sym link. Do I need any more setup or setting KUBECONFIG every time is
>>>> the way to go?
>>>>
>>>
>>> ​are you using our jenkins image?  our image includes the oc tooling.
>>>
>>> https://github.com/openshift/jenkins
>>> ​
>>>
>>>
>>>
>>>>
>>>> On 28 September 2016 at 22:51, Cesar Wong <cew...@redhat.com> wrote:
>>>>
>>>>> You can always create a new role that only allows the actions that you
>>>>> need to kick off a new build (create on builds and builds/source,  read on
>>>>> buildconfigs).
>>>>>
>>>>> Also, if you're running oc inside a pod within OpenShift, oc will use
>>>>> the credentials of the service account used to run the pod. No need to
>>>>> explicitly log in.
>>>>>
>>>>> On Sep 28, 2016, at 1:40 AM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Adding the edit cluster role seems to work.
>>>>>
>>>>> oadm policy add-cluster-role-to-user edit
>>>>> system:serviceaccount:jenkins:jenkins
>>>>>
>>>>> But is feels I'm giving it too much access. I tried with role
>>>>> system:build-controller but that wasn't enough.
>>>>>
>>>>> On 28 September 2016 at 14:00, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks. Invoking oc will do.
>>>>>>
>>>>>> I guess I have to oc login everytime?
>>>>>>
>>>>>> Somehow related question: can I have one service account with access
>>>>>> to start builds across all projects? I created a jenkins service account
>>>>>> for this purpose but I'm not sure how to give it access to all projects
>>>>>> instead of one by one.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27 September 2016 at 22:48, Clayton Coleman <ccole...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> There is an API for launching a binary build from a build config -
>>>>>>> you can do it from a curl call if necessary (run with --loglevel=8 to 
>>>>>>> see
>>>>>>> an example of that call).  You must send as the contents of the POST 
>>>>>>> call
>>>>>>> the source to build as a tar, zip, or tar.gz
>>>>>>>
>>>>>>> On Sep 27, 2016, at 6:35 AM, Ben Parees <bpar...@redhat.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sep 27, 2016 2:10 AM, "Lionel Orellana" <lione...@gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Hi
>>>>>>> >
>>>>>>> > Is it possible to t

Re: Failed to remove orphaned pod - device or resource busy

2016-10-04 Thread Lionel Orellana
docker run hello-world works.
On Tue., 4 Oct. 2016 at 8:06 pm, Michail Kargakis <mkarg...@redhat.com>
wrote:

> Can you run docker containers directly via the docker command?
>
> On Tue, Oct 4, 2016 at 10:18 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
> The deployment of the router hangs in Pending status. If I cancel the
> deployment, wait a little and try to deploy again I get
>
> "Deployment of version 3 awaiting cancellation of older running
> deployments"
>
> This shows in the logs:
>
> Oct 04 18:54:58 poc-docker02.aipo.gov.au origin-node[1773]: E1004
> 18:54:58.8054801815 kubelet.go:2684] *Failed cleaning pod*s: [remove
> /var/lib/origin/openshift.local.volumes/pods/0d0c9fa0-8624-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/default-token-36qqf: device or resource busy, remove
> /var/lib/origin/openshift.local.volumes/pods/10493062-89ce-11e6-827b-005056915814/volumes/
> kubernetes.io~secret/server-certificate: device or resource busy, remove
> /var/lib/origin/openshift.local.volumes/pods/104a80c3-89ce-11e6-827b-005056915814/volumes/
> kubernetes.io~nfs/pv-registry/.snapshot/hourly.2016-10-04_1505: *device
> or resource busy*, remove
> /var/lib/origin/openshift.local.volumes/pods/1204b6d2-8556-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/deployer-token-ygldd: *device or resource busy*,
> remove
> /var/lib/origin/openshift.local.volumes/pods/19f736b2-8619-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/deployer-token-lhbl7: device or resource busy,
> remove
> /var/lib/origin/openshift.local.volumes/pods/1a16e853-8460-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/builder-token-33845: device or resource busy, remove
> /var/lib/origin/openshift.local.volumes/pods/1a997bdd-7ed8-11e6-adb7-005056915814/volumes/
> kubernetes.io~secret/router-token-5qacw: *device or resource busy*,
> remove
> /var/lib/origin/openshift.local.volumes/pods/29857e2d-8554-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/builder-token-ftgao: device or resource busy, remove
> /var/lib/origin/openshift.local.volumes/pods/2f33e60b-854d-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/builder-token-ftgao: device or resource busy, remove
> /var/lib/origin/openshift.local.volumes/pods/3810b449-89d5-11e6-827b-005056915814/volumes/
> kubernetes.io~secret/deployer-token-1ehih: device or resource busy,
> remove
> /var/lib/origin/openshift.local.volumes/pods/3e5e918b-85e1-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/builder-dockercfg-4kyom-push: *device or resource
> busy*, remove
> /var/lib/origin/openshift.local.volumes/pods/3e8cc25e-85ee-11e6-83c1-005056915814/volumes/
> kubernetes.io~secret/builder-dockercfg-4kyom-
>
> If I then force-delete the old deployment pod by doing
>
>   oc delete pod router-2-deploy --grace-period=0
>
> then the next deployment starts and hangs in Pending again.
>
> A similar but smaller output appears in the logs
>
> Oct 04 18:55:14 poc-docker02.aipo.gov.au origin-node[1773]: I1004
> 18:55:14.4215021815 kubelet.go:2117] *Failed to remove orphaned pod*
> "1a997bdd-7ed8-11e6-adb7-005056915814" dir; err: remove
> /var/lib/origin/openshift.local.volumes/pods/1a997bdd-7ed8-11e6-adb7-005056915814/volumes/
> kubernetes.io~secret/router-token-5qacw: *device or resource busy*
>
> This device is a tmpfs mount.
>
> -bash-4.2$ sudo df -h | grep 1a997bdd
> tmpfs
>1.9G 0  1.9G   0%
> /var/lib/origin/openshift.local.volumes/pods/1a997bdd-7ed8-11e6-adb7-005056915814/volumes/
> kubernetes.io~secret/server-certificate
> tmpfs
>1.9G 0  1.9G   0%
> /var/lib/origin/openshift.local.volumes/pods/1a997bdd-7ed8-11e6-adb7-005056915814/volumes/
> kubernetes.io~secret/router-token-5qacw
> -bash-4.2$
>
> Restarting the docker daemon doesn't get rid of them. I'm well and truly
> stuck.
>
>
> On 4 October 2016 at 17:40, Lionel Orellana <lione...@gmail.com> wrote:
>
> All the "device or resource busy" errors seem related to tmpfs mounts for
> secret volumes.
>
>
>
> On 4 October 2016 at 17:32, Lionel Orellana <lione...@gmail.com> wrote:
>
> Hi All,
>
> I had a v1.3 cluster with a master and a node going. Both servers were
> rebooted over the weekend and all hell broke loose.
>
> The registry, the router and all apps I had running have stopped working.
>
> I see quite a few of these errors in the logs:
>
> Oct 04 17:14:07 poc-docker02.aipo.gov.au origin-node[1773]: I1004
> 17:14:07.5106151815 kubelet.go:2117] Failed to remove orphaned pod
> "c449d37f-8549-11e6-83c1-005056915814" dir; err: remove
> /var/lib/origin/openshift.local.volumes/pods/c449d37f-8549-11e6-83c1-005056915814/volumes/
> kub

Re: Failed to remove orphaned pod - device or resource busy

2016-10-04 Thread Lionel Orellana
All the "device or resource busy" errors seem related to tmpfs mounts for
secret volumes.



On 4 October 2016 at 17:32, Lionel Orellana <lione...@gmail.com> wrote:

> Hi All,
>
> I had a v1.3 cluster with a master and a node going. Both servers were
> rebooted over the weekend and all hell broke loose.
>
> The registry, the router and all apps I had running have stopped working.
>
> I see quite a few of these errors in the logs:
>
> Oct 04 17:14:07 poc-docker02.aipo.gov.au origin-node[1773]: I1004
> 17:14:07.5106151815 kubelet.go:2117] Failed to remove orphaned pod
> "c449d37f-8549-11e6-83c1-005056915814" dir; err: remove
> /var/lib/origin/openshift.local.volumes/pods/c449d37f-
> 8549-11e6-83c1-005056915814/volumes/kubernetes.io~secret/
> builder-token-ftgao:* device or resource busy*
>
> I don't really know what happened, how I got into this state. The registry
> is stuck in "Container Creating".  If I start a new deployment of the
> router the deployment pod doesn't get past "Pending".
>
> Seems like I can't delete pods either. They get stuck in "Terminating".
>
> Not sure how to narrow this down. Any help greatly appreciated.
>
> Thanks
>
> Lionel.
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Failed to remove orphaned pod - device or resource busy

2016-10-04 Thread Lionel Orellana
Hi All,

I had a v1.3 cluster with a master and a node going. Both servers were
rebooted over the weekend and all hell broke loose.

The registry, the router and all apps I had running have stopped working.

I see quite a few of these errors in the logs:

Oct 04 17:14:07 poc-docker02.aipo.gov.au origin-node[1773]: I1004
17:14:07.5106151815 kubelet.go:2117] Failed to remove orphaned pod
"c449d37f-8549-11e6-83c1-005056915814" dir; err: remove
/var/lib/origin/openshift.local.volumes/pods/c449d37f-8549-11e6-83c1-005056915814/volumes/
kubernetes.io~secret/builder-token-ftgao:* device or resource busy*

I don't really know what happened, how I got into this state. The registry
is stuck in "Container Creating".  If I start a new deployment of the
router the deployment pod doesn't get past "Pending".

Seems like I can't delete pods either. They get stuck in "Terminating".

Not sure how to narrow this down. Any help greatly appreciated.

Thanks

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


Re: Modifying existing advanced installation

2016-09-28 Thread Lionel Orellana
Thanks Jason. Good to know I'm on the right track.

On 23 September 2016 at 03:52, Jason DeTiberus <jdeti...@redhat.com> wrote:

>
>
> On Tue, Sep 20, 2016 at 4:07 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hello
>>
>> I want to configure LDAP authentication on my existing cluster.
>>
>> Instead of manually modifying the master config file, can I add the new
>> settings to my Ansible inventory and rerun the config playbook?
>>
>
> Yes, you can update your inventory and re-run Ansible.
>
>
>> Does it know to only apply the new configuration?
>>
>
> It will re-run the entire config playbook. There are some steps that will
> not be applied automatically (certificate creation, router, registry,
> logging, metrics), and there are some tasks that may report "changed" when
> they have not actually modified anything. We are working on improving the
> roles for better suitability for ongoing configuration management.
>
>
>> Generally speaking, is this the best way to make changes to an existing
>> cluster?
>>
>
> It is the way that I would recommend, yes.
>
>
>
>>
>> Thanks
>>
>> Lionel.
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Jason DeTiberus
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Jenkins plugin - binary build

2016-09-28 Thread Lionel Orellana
Ah I am running Jenkins inside a pod and invoking oc from there. Thanks for
the tip.

Before I can run oc I'm having to set KUBECONFIG to some location I know I
can write to.

Otherwise I get this error when running any oc command:

error: KUBECONFIG is set to a file that cannot be created or modified:
/.kube/config
mkdir /.kube: permission denied

To install the client I simply downloaded the tar, unpacked and created a
sym link. Do I need any more setup or setting KUBECONFIG every time is the
way to go?

On 28 September 2016 at 22:51, Cesar Wong <cew...@redhat.com> wrote:

> You can always create a new role that only allows the actions that you
> need to kick off a new build (create on builds and builds/source,  read on
> buildconfigs).
>
> Also, if you're running oc inside a pod within OpenShift, oc will use the
> credentials of the service account used to run the pod. No need to
> explicitly log in.
>
> On Sep 28, 2016, at 1:40 AM, Lionel Orellana <lione...@gmail.com> wrote:
>
> Adding the edit cluster role seems to work.
>
> oadm policy add-cluster-role-to-user edit system:serviceaccount:jenkins:
> jenkins
>
> But is feels I'm giving it too much access. I tried with role
> system:build-controller but that wasn't enough.
>
> On 28 September 2016 at 14:00, Lionel Orellana <lione...@gmail.com> wrote:
>
>> Thanks. Invoking oc will do.
>>
>> I guess I have to oc login everytime?
>>
>> Somehow related question: can I have one service account with access to
>> start builds across all projects? I created a jenkins service account for
>> this purpose but I'm not sure how to give it access to all projects instead
>> of one by one.
>>
>>
>>
>>
>>
>> On 27 September 2016 at 22:48, Clayton Coleman <ccole...@redhat.com>
>> wrote:
>>
>>> There is an API for launching a binary build from a build config - you
>>> can do it from a curl call if necessary (run with --loglevel=8 to see an
>>> example of that call).  You must send as the contents of the POST call the
>>> source to build as a tar, zip, or tar.gz
>>>
>>> On Sep 27, 2016, at 6:35 AM, Ben Parees <bpar...@redhat.com> wrote:
>>>
>>>
>>>
>>> On Sep 27, 2016 2:10 AM, "Lionel Orellana" <lione...@gmail.com> wrote:
>>> >
>>> > Hi
>>> >
>>> > Is it possible to trigger a binary build in Jenkins using
>>> the openshiftBuild step?
>>> >
>>> > I'm basically trying to run something like
>>> >
>>> > oc start-build  --from-dir=
>>> >
>>> > but there's no option to pass from-dir in the openshiftBuild step. Are
>>> there plans to support this?
>>>
>>> It's not possible today, but yes it is on our list. In the meantime you
>>> can shell out and invoke oc directly to accomplish the same thing.
>>>
>>> >
>>> > Thanks
>>> >
>>> >
>>> > Lionel.
>>> >
>>> > ___
>>> > users mailing list
>>> > users@lists.openshift.redhat.com
>>> > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>> >
>>>
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Binary build - numeric overflow in sparse archive member

2016-09-28 Thread Lionel Orellana
Hi


Running start-build with --from-dir option is resulting in the
following output.


Uploading directory "transaction-authority-lite" as binary input for
the build ...

build "transaction-auth-lite-3" started
Receiving source from STDIN as archive ...
Extracting...
tar: CoreUtils.java.svn-base: numeric overflow in sparse archive member
tar: weblogic-application.xml.svn-base: numeric overflow in sparse
archive member




It's not just svn-base files. Regular java files and other types throw the
same error.


I have another binary build which is working fine albeit with less files in it.


Any ideas how to get around this?


-bash-4.2$ oc version
oc v1.3.0
kubernetes v1.3.0+52492b4
features: Basic-Auth GSSAPI Kerberos SPNEGO

Thanks



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


Re: Jenkins plugin - binary build

2016-09-27 Thread Lionel Orellana
Adding the edit cluster role seems to work.

oadm policy add-cluster-role-to-user edit
system:serviceaccount:jenkins:jenkins

But is feels I'm giving it too much access. I tried with role
system:build-controller but that wasn't enough.

On 28 September 2016 at 14:00, Lionel Orellana <lione...@gmail.com> wrote:

> Thanks. Invoking oc will do.
>
> I guess I have to oc login everytime?
>
> Somehow related question: can I have one service account with access to
> start builds across all projects? I created a jenkins service account for
> this purpose but I'm not sure how to give it access to all projects instead
> of one by one.
>
>
>
>
>
> On 27 September 2016 at 22:48, Clayton Coleman <ccole...@redhat.com>
> wrote:
>
>> There is an API for launching a binary build from a build config - you
>> can do it from a curl call if necessary (run with --loglevel=8 to see an
>> example of that call).  You must send as the contents of the POST call the
>> source to build as a tar, zip, or tar.gz
>>
>> On Sep 27, 2016, at 6:35 AM, Ben Parees <bpar...@redhat.com> wrote:
>>
>>
>>
>> On Sep 27, 2016 2:10 AM, "Lionel Orellana" <lione...@gmail.com> wrote:
>> >
>> > Hi
>> >
>> > Is it possible to trigger a binary build in Jenkins using
>> the openshiftBuild step?
>> >
>> > I'm basically trying to run something like
>> >
>> > oc start-build  --from-dir=
>> >
>> > but there's no option to pass from-dir in the openshiftBuild step. Are
>> there plans to support this?
>>
>> It's not possible today, but yes it is on our list. In the meantime you
>> can shell out and invoke oc directly to accomplish the same thing.
>>
>> >
>> > Thanks
>> >
>> >
>> > Lionel.
>> >
>> > ___
>> > users mailing list
>> > users@lists.openshift.redhat.com
>> > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>> >
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Modifying existing advanced installation

2016-09-20 Thread Lionel Orellana
Hello

I want to configure LDAP authentication on my existing cluster.

Instead of manually modifying the master config file, can I add the new
settings to my Ansible inventory and rerun the config playbook? Does it
know to only apply the new configuration? Generally speaking, is this the
best way to make changes to an existing cluster?

Thanks

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


Re: how to set no_proxy for s2i registry push?

2016-09-19 Thread Lionel Orellana
Adding the registry's address to NO_PROXY in /etc/sysconfig/docker works.

However it doesn't feel like something I should be changing by hand. Is
this something I missed in the ansible configuration when installing?

On 20 September 2016 at 14:09, Lionel Orellana <lione...@gmail.com> wrote:

> Hi
>
> I'm getting this error when building the wildfly:10  builder sample on a
> containerised v1.3.0.
>
> ushing image 172.19.38.253:5000/bimorl/wildfly:latest ...
> Registry server Address:
> Registry server User Name: serviceaccount
> Registry server Email: serviceacco...@example.org
> Registry server Password: <>
> error: build error: Failed to push image: Error: Status 503 trying to push
> repository bimorl/wildfly:
> ERROR: The requested URL could not be retrieved
> Connection to 172.19.38.253 failed.\n\n\n id=\"sysmsg\">The system returned: (145) Connection timed
> out\n\nThe remote host or network may be down. Please try the
> request again.
>
> curl fails with the same error but succeeds if I use --no-proxy
>
> I set Environment="NO_PROXY=172.19.38.253" in 
> /etc/systemd/system/docker.service.d/http-proxy.conf
> on all hosts to no avail.
>
> Where should I set no_proxy for this?
>
> Thanks
>
> Lionel.
>
>
>
>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


how to set no_proxy for s2i registry push?

2016-09-19 Thread Lionel Orellana
Hi

I'm getting this error when building the wildfly:10  builder sample on a
containerised v1.3.0.

ushing image 172.19.38.253:5000/bimorl/wildfly:latest ...
Registry server Address:
Registry server User Name: serviceaccount
Registry server Email: serviceacco...@example.org
Registry server Password: <>
error: build error: Failed to push image: Error: Status 503 trying to push
repository bimorl/wildfly:
ERROR: The requested URL could not be retrieved
Connection to 172.19.38.253 failed.\n\n\nThe system returned: (145) Connection timed
out\n\nThe remote host or network may be down. Please try the
request again.

curl fails with the same error but succeeds if I use --no-proxy

I set Environment="NO_PROXY=172.19.38.253"
in /etc/systemd/system/docker.service.d/http-proxy.conf on all hosts to no
avail.

Where should I set no_proxy for this?

Thanks

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


Re: Can't run containers after advanced installation

2016-09-19 Thread Lionel Orellana
Adding -b=lbr0 --mtu=1450 to the docker daemon options
in /etc/systemd/system/docker.service.d/startup.conf seems to fix it.

The host already had docker installed so perhaps the installation didn't
bother passing or somehow setting those options from
/run/openshift-sdn/docker-network.



On 16 September 2016 at 17:57, Lionel Orellana <lione...@gmail.com> wrote:

> Hi All
>
> I installed Origin v1.3.0-rc1 (unaware of the imminent 1.3 release) using
> the ansible method.
> Everything seemed to have installed Ok. But whenever I try to build or run
> anything I get this type of error:
>
> Error syncing pod, skipping: failed to "StartContainer" for "POD" with
> RunContainerError: "runContainer: Error response from daemon: failed to
> create endpoint k8s_POD.4a82dc9f_nodejs-example-2-build_bimorl_
> 7194e4a4-7bcd-11e6-ab95-005056915814_cd78594e on network bridge: adding
> interface veth7932aba to bridge docker0 failed: could not find bridge
> docker0: route ip+net: no such network interface"
>
> On the host running a simple docker image fails too.
>
> bash-4.2$ sudo docker run hello-world
> docker: Error response from daemon: failed to create endpoint
> ecstatic_ramanujan on network bridge: adding interface veth59decae to
> bridge docker0 failed: could not find bridge docker0: route ip+net: no such
> network interface.
>
> I have restarted the docker service several times with no effect. docker0
> appears briefly when i do netstat -nr but then disappears again.
>
> docker version 1.10.3
> RHEL 7.2.
>
> Thanks
>
> Lionel.
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Origin v1.3.0 released

2016-09-16 Thread Lionel Orellana
Thanks Clayton. Congrats to all on the new release!

Just a few hours earlier I was installing 1.3.0rc1 using ansible. Good
chance now for me to learn how upgrades work.

I'm trying to upgrade to 1.3
using 
openshift-ansible/playbooks/byo/openshift-cluster/upgrades/v3_3/upgrade.yml.
I set the openshift_release to v1.3.0 in the inventory file. But it's not
happy:

"openshift_release is 1.3.0 which is not a valid release for a 1.3 upgrade"

Do I need to wait for the ansible upgrade playbooks to be updated?


Thanks.


Lionel



On 16 September 2016 at 15:15, Clayton Coleman  wrote:

> And of course I almost forget - the *fastest* way to get v1.3.0 is:
>
> $ oc cluster up --version=v1.3.0
>
> Enjoy!
>
> On Fri, Sep 16, 2016 at 12:51 AM, Clayton Coleman 
> wrote:
>
>> Images have been pushed to the hub and release binaries are up on GitHub
>> under release v1.3.0
>> .  RPMs will
>> take a few days to show up in the existing channels.
>>
>> v1.3.0 was a huge release - thanks to everyone who contributed to make it
>> possible.  You can see a list of delivered changes on the 1.3 roadmap
>> https://ci.openshift.redhat.com/releases_overview.html#3.3 as well as on
>> the individual GitHub release pages for alpha.1 -> rc1.  Please give
>> feedback or report any issues you see.
>>
>> Origin 1.4 will pick up Kube 1.4 and contain a number of more targeted
>> features as you can see on the release roadmap
>> https://ci.openshift.redhat.com/releases_overview.html#3.4.  The rebase
>> has landed in master and we will reopen the queue for changes in the
>> morning.  We're also hard at work on Kubernetes 1.5 in the upstream
>> community - don't hesitate to get involved there as well.
>>
>> Thanks!
>>
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: Registry login with service account

2016-08-21 Thread Lionel Orellana
There's a -z option when you add a role to a service account that I was
missing.

oc adm policy add-role-to-user system:image-builder -z 

Also make sure the project you are trying to push to is active when you add
the role.

It would be really helpful if the oc client threw an error when adding a
role to user that doesn't exist.
On Mon, 22 Aug 2016 at 2:24 PM, Lionel Orellana <lione...@gmail.com> wrote:

> Hi
>
> I'm trying to use a service account to push images to the openshift
> registry.
>
> I am able to login and push with a regular user token obtained from oc
> whoami -t. But that token expires after a while so I need a more permanent
> solution.
>
> I created a service account and added the following roles:
> system:image-builder, system:registry, edit. I got the token out of the
> service account secret and logged in successfully to the openshift
> registry. However when I try to push an image to it I get 'unauthorized:
> authentication required'.
>
> Sounds like it doesn't have the right permissions but I can't figure out
> why.
>
> Any ideas?
>
> Thanks
>
>
> Lionel.
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Registry login with service account

2016-08-21 Thread Lionel Orellana
Hi

I'm trying to use a service account to push images to the openshift
registry.

I am able to login and push with a regular user token obtained from oc
whoami -t. But that token expires after a while so I need a more permanent
solution.

I created a service account and added the following roles:
system:image-builder, system:registry, edit. I got the token out of the
service account secret and logged in successfully to the openshift
registry. However when I try to push an image to it I get 'unauthorized:
authentication required'.

Sounds like it doesn't have the right permissions but I can't figure out
why.

Any ideas?

Thanks

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


Re: s2i maven proxy

2016-08-12 Thread Lionel Orellana
Got it.

name: MAVEN_OPTS

value: '-DproxyHost=http:// <http://172.30.192.51:3128/>
 -DproxyPort='

On 13 August 2016 at 08:08, Lionel Orellana <lione...@gmail.com> wrote:

> Hi,
>
> I'm trying to run the Wildfly 10 template from the console.
>
> I found how to set the proxy variables for git and it is pulling down the
> repo fine.
>
> But maven can't connect to central.
>
> Unknown host repo1.maven.org: unknown error
>
>
> I've tried different environment variables with no luck
>
>
> strategy:
>
> type: Source
>
> sourceStrategy:
>
>   from:
>
> kind: ImageStreamTag
>
> namespace: openshift
>
> name: 'wildfly:10.0'
>
>   env:
>
> -
>
>   name: HTTPS_PROXY
>
>   value: 'http://: <http://172.30.192.51:3128/>
> '
>
> -
>
>   name: HTTP_PROXY
>
>   value: 'http://: <http://172.30.192.51:3128/>
> '
>
> -
>
>   name: JAVA_OPTS
>
>   value: '-Dhttp.proxyHost='http://
> <http://172.30.192.51:3128/>' -Dhttp.proxyPort='
>
>
> Is there a way to set this here or can it only be done in the s2i script
> and the build image ?
>
>
>
> Thanks
>
>
>
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: cluster up - reuse registry address

2016-08-11 Thread Lionel Orellana
Yes.

On 10 August 2016 at 18:04, Cesar Wong <cew...@redhat.com> wrote:

> Lionel,
>
> So is it working for you now?
>
> On Aug 9, 2016, at 11:10 PM, Lionel Orellana <lione...@gmail.com> wrote:
>
> Digging through the go libraries used for parsing the command options I
> found that setting the no_proxy variable like this works:
>
> -e \"no_proxy=172.17.0.3,172.17.0.4\"
>
> It all comes down to https://golang.org/pkg/encoding/csv
>
> which is used by the pflag package.
> On Tue, 9 Aug 2016 at 10:31 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Setting the log level to 4 I found the following
>>
>>   Starting OpenShift using container 'origin'
>> I0809 22:21:26.415373   20151 run.go:143] Creating container named
>> "origin"
>> config:
>>   image: openshift/origin:v1.3.0-alpha.2
>>   command:
>> start
>> --master-config=/var/lib/origin/openshift.local.config/
>> master/master-config.yaml
>> --node-config=/var/lib/origin/openshift.local.config/node-
>> poc-docker03.aipo.gov.au/node-config.yaml
>>   environment:
>> http_proxy=http://proxy.aipo.gov.au:3128
>> https_proxy=http://proxy.aipo.gov.au:3128
>>* no_proxy=172.17.0.3*
>> *172.17.0.4*
>>
>> I've tried different ways of setting multiple ip's in no_proxy but they
>> always seem to be getting split on the comma.
>>
>> -e "no_proxy=172.17.0.3,172.17.0.4"
>> -e no_proxy="172.17.0.3\,172.17.0.4"
>> -e no_proxy=’172.17.0.3,172.17.0.4’
>> -e no_proxy=172.17.0.3,172.17.0.4
>>
>> This might be causing some of my problems. The fact that I can't set more
>> than one ip address in no_proxy.
>>
>>
>>
>>
>>
>>
>>
>> On 9 August 2016 at 11:18, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> I guess what I need is a way to configure the proxy as per
>>> https://docs.openshift.org/latest/install_config/http_
>>> proxies.html#configuring-hosts-for-proxies
>>>
>>>
>>> On Tue, 9 Aug 2016 at 10:05 AM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> It's been difficult to get a functional poc going with oc cluster up
>>>> behind a proxy.
>>>>
>>>> I need to maintain the registry's address so I can add it to the
>>>> no_proxy variable of the docker deamon. Clayton's procedure works for
>>>> reusing the address . I will try --use-existing-config.
>>>>
>>>> But I also need to add the registry's internal address (which always
>>>> seems to be initially set to 172.17.0.4) to the no_proxy variable of the
>>>> cluster up command itself. Otherwise the health checks try to go through
>>>> the proxy and fail.
>>>>
>>>> When I recreate the registry (in order to set a known service ip) the
>>>> pod ip changes and the health checks start to fail again.
>>>>
>>>> Obviously I am making this harder than it should be. But I just can't
>>>> get the right combination to run a cluster behind a proxy where I can login
>>>> to the registry (docker login). Maybe I should have said that's what I'm
>>>> trying to do from the beginning.
>>>>
>>>> Cheers
>>>>
>>>>
>>>> Lionel.
>>>>
>>>> On Tue, 9 Aug 2016 at 1:16 AM, Clayton Coleman <ccole...@redhat.com>
>>>> wrote:
>>>>
>>>>> Generally deep configuration is not the goal of oc cluster up - that's
>>>>> more the Ansible installs responsibility.  oc cluster up is about getting 
>>>>> a
>>>>> running cluster up for test / dev as quickly as possible, but we don't 
>>>>> want
>>>>> to add fine grained tuning to it.
>>>>>
>>>>> On Mon, Aug 8, 2016 at 10:49 AM, Cesar Wong <cew...@redhat.com> wrote:
>>>>>
>>>>>> Hi Lionel,
>>>>>>
>>>>>> You can always reuse the same data/config dirs and keep your service
>>>>>> ips:
>>>>>>
>>>>>> oc cluster up --host-data-dir=blah --host-config-dir=blah
>>>>>> --use-existing-config
>>>>>>
>>>>>> On Aug 7, 2016, at 9:17 PM, Lionel Orellana <lione...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks Clayton.
>>>>>>
>>>>>> Wou

Re: cluster up - reuse registry address

2016-08-09 Thread Lionel Orellana
Digging through the go libraries used for parsing the command options I
found that setting the no_proxy variable like this works:

-e \"no_proxy=172.17.0.3,172.17.0.4\"

It all comes down to https://golang.org/pkg/encoding/csv

which is used by the pflag package.
On Tue, 9 Aug 2016 at 10:31 PM, Lionel Orellana <lione...@gmail.com> wrote:

> Setting the log level to 4 I found the following
>
>   Starting OpenShift using container 'origin'
>
> I0809 22:21:26.415373   20151 run.go:143] Creating container named "origin"
>
> config:
>
>   image: openshift/origin:v1.3.0-alpha.2
>
>   command:
>
> start
>
>
> --master-config=/var/lib/origin/openshift.local.config/master/master-config.yaml
>
> --node-config=/var/lib/origin/openshift.local.config/
> node-poc-docker03.aipo.gov.au/node-config.yaml
>
>   environment:
>
> http_proxy=http://proxy.aipo.gov.au:3128
>
> https_proxy=http://proxy.aipo.gov.au:3128
>
>* no_proxy=172.17.0.3*
>
> *172.17.0.4*
>
> I've tried different ways of setting multiple ip's in no_proxy but they
> always seem to be getting split on the comma.
>
> -e "no_proxy=172.17.0.3,172.17.0.4"
>
> -e no_proxy="172.17.0.3\,172.17.0.4"
>
> -e no_proxy=’172.17.0.3,172.17.0.4’
> -e no_proxy=172.17.0.3,172.17.0.4
>
> This might be causing some of my problems. The fact that I can't set more
> than one ip address in no_proxy.
>
>
>
>
>
>
>
> On 9 August 2016 at 11:18, Lionel Orellana <lione...@gmail.com> wrote:
>
>> I guess what I need is a way to configure the proxy as per
>> https://docs.openshift.org/latest/install_config/http_proxies.html#configuring-hosts-for-proxies
>>
>>
>> On Tue, 9 Aug 2016 at 10:05 AM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> It's been difficult to get a functional poc going with oc cluster up
>>> behind a proxy.
>>>
>>> I need to maintain the registry's address so I can add it to the
>>> no_proxy variable of the docker deamon. Clayton's procedure works for
>>> reusing the address . I will try --use-existing-config.
>>>
>>> But I also need to add the registry's internal address (which always
>>> seems to be initially set to 172.17.0.4) to the no_proxy variable of the
>>> cluster up command itself. Otherwise the health checks try to go through
>>> the proxy and fail.
>>>
>>> When I recreate the registry (in order to set a known service ip) the
>>> pod ip changes and the health checks start to fail again.
>>>
>>> Obviously I am making this harder than it should be. But I just can't
>>> get the right combination to run a cluster behind a proxy where I can login
>>> to the registry (docker login). Maybe I should have said that's what I'm
>>> trying to do from the beginning.
>>>
>>> Cheers
>>>
>>>
>>> Lionel.
>>>
>>> On Tue, 9 Aug 2016 at 1:16 AM, Clayton Coleman <ccole...@redhat.com>
>>> wrote:
>>>
>>>> Generally deep configuration is not the goal of oc cluster up - that's
>>>> more the Ansible installs responsibility.  oc cluster up is about getting a
>>>> running cluster up for test / dev as quickly as possible, but we don't want
>>>> to add fine grained tuning to it.
>>>>
>>>> On Mon, Aug 8, 2016 at 10:49 AM, Cesar Wong <cew...@redhat.com> wrote:
>>>>
>>>>> Hi Lionel,
>>>>>
>>>>> You can always reuse the same data/config dirs and keep your service
>>>>> ips:
>>>>>
>>>>> oc cluster up --host-data-dir=blah --host-config-dir=blah
>>>>> --use-existing-config
>>>>>
>>>>> On Aug 7, 2016, at 9:17 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Thanks Clayton.
>>>>>
>>>>> Would be nice to have a way of setting the address when using cluster
>>>>> up though.
>>>>> On Mon, 8 Aug 2016 at 11:03 AM, Clayton Coleman <ccole...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> When you create the registry you can specify the service IP that is
>>>>>> assigned (as long as another service hasn't claimed it).
>>>>>>
>>>>>> $ oadm registry -o yaml > registry.yaml
>>>>>> $ vi registry.yaml
>>>>>> # Set

Re: cluster up - reuse registry address

2016-08-09 Thread Lionel Orellana
Setting the log level to 4 I found the following

  Starting OpenShift using container 'origin'

I0809 22:21:26.415373   20151 run.go:143] Creating container named "origin"

config:

  image: openshift/origin:v1.3.0-alpha.2

  command:

start

--master-config=/var/lib/origin/openshift.local.config/maste
r/master-config.yaml

--node-config=/var/lib/origin/openshift.local.config/node-po
c-docker03.aipo.gov.au/node-config.yaml

  environment:

http_proxy=http://proxy.aipo.gov.au:3128

https_proxy=http://proxy.aipo.gov.au:3128

   * no_proxy=172.17.0.3*

*172.17.0.4*

I've tried different ways of setting multiple ip's in no_proxy but they
always seem to be getting split on the comma.

-e "no_proxy=172.17.0.3,172.17.0.4"

-e no_proxy="172.17.0.3\,172.17.0.4"

-e no_proxy=’172.17.0.3,172.17.0.4’
-e no_proxy=172.17.0.3,172.17.0.4

This might be causing some of my problems. The fact that I can't set more
than one ip address in no_proxy.







On 9 August 2016 at 11:18, Lionel Orellana <lione...@gmail.com> wrote:

> I guess what I need is a way to configure the proxy as per
> https://docs.openshift.org/latest/install_config/http_
> proxies.html#configuring-hosts-for-proxies
>
>
> On Tue, 9 Aug 2016 at 10:05 AM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> It's been difficult to get a functional poc going with oc cluster up
>> behind a proxy.
>>
>> I need to maintain the registry's address so I can add it to the no_proxy
>> variable of the docker deamon. Clayton's procedure works for reusing the
>> address . I will try --use-existing-config.
>>
>> But I also need to add the registry's internal address (which always
>> seems to be initially set to 172.17.0.4) to the no_proxy variable of the
>> cluster up command itself. Otherwise the health checks try to go through
>> the proxy and fail.
>>
>> When I recreate the registry (in order to set a known service ip) the pod
>> ip changes and the health checks start to fail again.
>>
>> Obviously I am making this harder than it should be. But I just can't get
>> the right combination to run a cluster behind a proxy where I can login to
>> the registry (docker login). Maybe I should have said that's what I'm
>> trying to do from the beginning.
>>
>> Cheers
>>
>>
>> Lionel.
>>
>> On Tue, 9 Aug 2016 at 1:16 AM, Clayton Coleman <ccole...@redhat.com>
>> wrote:
>>
>>> Generally deep configuration is not the goal of oc cluster up - that's
>>> more the Ansible installs responsibility.  oc cluster up is about getting a
>>> running cluster up for test / dev as quickly as possible, but we don't want
>>> to add fine grained tuning to it.
>>>
>>> On Mon, Aug 8, 2016 at 10:49 AM, Cesar Wong <cew...@redhat.com> wrote:
>>>
>>>> Hi Lionel,
>>>>
>>>> You can always reuse the same data/config dirs and keep your service
>>>> ips:
>>>>
>>>> oc cluster up --host-data-dir=blah --host-config-dir=blah
>>>> --use-existing-config
>>>>
>>>> On Aug 7, 2016, at 9:17 PM, Lionel Orellana <lione...@gmail.com> wrote:
>>>>
>>>> Thanks Clayton.
>>>>
>>>> Would be nice to have a way of setting the address when using cluster
>>>> up though.
>>>> On Mon, 8 Aug 2016 at 11:03 AM, Clayton Coleman <ccole...@redhat.com>
>>>> wrote:
>>>>
>>>>> When you create the registry you can specify the service IP that is
>>>>> assigned (as long as another service hasn't claimed it).
>>>>>
>>>>> $ oadm registry -o yaml > registry.yaml
>>>>> $ vi registry.yaml
>>>>> # Set the registry service `spec.clusterIP` field to a valid
>>>>> service IP (must be within the service CIDR, typically 172.30.0.0/16)
>>>>> $ oc create -f registry.yaml
>>>>>
>>>>>
>>>>> On Sun, Aug 7, 2016 at 8:55 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I'm facing a similar problem to this: https://github.com/openshift/
>>>>>> origin/issues/7879
>>>>>>
>>>>>> Basically I need to configure the NO_PROXY variable of the Docker
>>>>>> deamon to include the registry address. Problem is with cluster up I 
>>>>>> can't
>>>>>> control the ip address that will be assigned to the registry. Or at 
>>>>>> least I
>>>>>> can't find a way to do it. Is there an option that I'm not seeing?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Lionel.
>>>>>>
>>>>>> ___
>>>>>> users mailing list
>>>>>> users@lists.openshift.redhat.com
>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>>
>>>>>>
>>>>> ___
>>>> users mailing list
>>>> users@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>>
>>>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: cluster up - reuse registry address

2016-08-08 Thread Lionel Orellana
I guess what I need is a way to configure the proxy as per
https://docs.openshift.org/latest/install_config/http_proxies.html#configuring-hosts-for-proxies

On Tue, 9 Aug 2016 at 10:05 AM, Lionel Orellana <lione...@gmail.com> wrote:

> It's been difficult to get a functional poc going with oc cluster up
> behind a proxy.
>
> I need to maintain the registry's address so I can add it to the no_proxy
> variable of the docker deamon. Clayton's procedure works for reusing the
> address . I will try --use-existing-config.
>
> But I also need to add the registry's internal address (which always seems
> to be initially set to 172.17.0.4) to the no_proxy variable of the cluster
> up command itself. Otherwise the health checks try to go through the proxy
> and fail.
>
> When I recreate the registry (in order to set a known service ip) the pod
> ip changes and the health checks start to fail again.
>
> Obviously I am making this harder than it should be. But I just can't get
> the right combination to run a cluster behind a proxy where I can login to
> the registry (docker login). Maybe I should have said that's what I'm
> trying to do from the beginning.
>
> Cheers
>
>
> Lionel.
>
> On Tue, 9 Aug 2016 at 1:16 AM, Clayton Coleman <ccole...@redhat.com>
> wrote:
>
>> Generally deep configuration is not the goal of oc cluster up - that's
>> more the Ansible installs responsibility.  oc cluster up is about getting a
>> running cluster up for test / dev as quickly as possible, but we don't want
>> to add fine grained tuning to it.
>>
>> On Mon, Aug 8, 2016 at 10:49 AM, Cesar Wong <cew...@redhat.com> wrote:
>>
>>> Hi Lionel,
>>>
>>> You can always reuse the same data/config dirs and keep your service ips:
>>>
>>> oc cluster up --host-data-dir=blah --host-config-dir=blah
>>> --use-existing-config
>>>
>>> On Aug 7, 2016, at 9:17 PM, Lionel Orellana <lione...@gmail.com> wrote:
>>>
>>> Thanks Clayton.
>>>
>>> Would be nice to have a way of setting the address when using cluster up
>>> though.
>>> On Mon, 8 Aug 2016 at 11:03 AM, Clayton Coleman <ccole...@redhat.com>
>>> wrote:
>>>
>>>> When you create the registry you can specify the service IP that is
>>>> assigned (as long as another service hasn't claimed it).
>>>>
>>>> $ oadm registry -o yaml > registry.yaml
>>>> $ vi registry.yaml
>>>> # Set the registry service `spec.clusterIP` field to a valid
>>>> service IP (must be within the service CIDR, typically 172.30.0.0/16)
>>>> $ oc create -f registry.yaml
>>>>
>>>>
>>>> On Sun, Aug 7, 2016 at 8:55 PM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'm facing a similar problem to this:
>>>>> https://github.com/openshift/origin/issues/7879
>>>>>
>>>>> Basically I need to configure the NO_PROXY variable of the Docker
>>>>> deamon to include the registry address. Problem is with cluster up I can't
>>>>> control the ip address that will be assigned to the registry. Or at least 
>>>>> I
>>>>> can't find a way to do it. Is there an option that I'm not seeing?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Lionel.
>>>>>
>>>>> ___
>>>>> users mailing list
>>>>> users@lists.openshift.redhat.com
>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>>
>>>>>
>>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>>
>>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: No external access inside container

2016-08-04 Thread Lionel Orellana
Thanks Ben.

I must have been doing something silly because I recreated the cluster,
configured the proxy directly in the Jenkins ui and everything worked as
expected.

However I had issues with creating other apps via new-app (using the
Jenkins template did work). new-app couldn't connect to the public
registry. To get around this I set the proxy environment variables as
arguments to the oc cluster up command.

oc cluster up -e http_proxy=http://: -e
https_proxy=http://:

Then I could create apps with new-app but the openshift registry was not
happy. It started, but the health checks failed and it got killed.

"Readiness probe failed: Get http://172.17.0.4:5000/healthz: read tcp :46708->:: read: connection reset by peer"

So it was trying to use the proxy to hit the registry.

To fix that I passed no_proxy=172.17.0.4:5000 to cluster up.

If the registry gets a different internal ip address this will break of
course. I suspect I will have other issues if internal traffic is being
pushed out to the proxy but we'll cross that bridge when we get to it.
Unless someone can save me the headaches.

Thanks again.

Lionel.



On Wed, 3 Aug 2016 at 12:16 PM, Ben Parees <bpar...@redhat.com> wrote:

> On Mon, Aug 1, 2016 at 11:07 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Hello
>>
>> I ran a cluster with oc cluster up and deployed Jenkins from the provided
>> template. I can acces Jenkins and login. But I need to setup our company
>> proxy so Jenkins can access external sites (eg. Github.com).
>>
>> From within the container (oc rsh jenkins-5-xg14g) curl fails to connect
>> to github.com. From the host it connects fine. I ran these commands to
>> try add the proxy settings to the container:
>>
>> oc env dc/jenkins HTTPS_PROXY=server:port
>> oc env dc/jenkins HTTP_PROXY=server:port
>>
>> The container was redeployed and I can see the new env vars in the
>> console. But still can't access the internet.
>>
>
> ​if you oc rsh into the container and poke around, can you get external
> access?  (after setting proxy env variables within your rsh session to
> ensure they are available)
>
> note that there are a couple ways to configure a proxy for curl:
> http://stackoverflow.com/questions/9445489/linux-curl-command-with-proxy
>
> also there's some lack of consistency on what is supported in terms of
> HTTP_PROXY because http_proxy is the standard so you might try setting your
> env variables with lower case.
>
> http://unix.stackexchange.com/questions/212894/whats-the-right-format-for-the-http-proxy-environment-variable-caps-or-no-ca
> ​
>
>
>
>>
>> oc get hostsubnet returns nothing.
>>
>> Versions:
>> oc v1.3.0-alpha.2
>> Docker 1.10.3
>> Rhel 7.2
>>
>> Thanks for any help.
>>
>> Lionel.
>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


No external access inside container

2016-08-01 Thread Lionel Orellana
Hello

I ran a cluster with oc cluster up and deployed Jenkins from the provided
template. I can acces Jenkins and login. But I need to setup our company
proxy so Jenkins can access external sites (eg. Github.com).

>From within the container (oc rsh jenkins-5-xg14g) curl fails to connect to
github.com. From the host it connects fine. I ran these commands to try add
the proxy settings to the container:

oc env dc/jenkins HTTPS_PROXY=server:port
oc env dc/jenkins HTTP_PROXY=server:port

The container was redeployed and I can see the new env vars in the console.
But still can't access the internet.

oc get hostsubnet returns nothing.

Versions:
oc v1.3.0-alpha.2
Docker 1.10.3
Rhel 7.2

Thanks for any help.

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


Re: oc cluster up - dns issue?

2016-07-29 Thread Lionel Orellana
I can start haproxy by itself on port 80. Don't know what's going on. This
is a server on DigitalOcean. I tried on a local vm and everything works
fine.

On 28 July 2016 at 12:25, Clayton Coleman <ccole...@redhat.com> wrote:

> From the host, can you start anything binding to 80?  Is it just when
> running from containers with host networking?  The router runs with
> --net=host, so it's possible this is a docker 1.11 bug (although I haven't
> heard anyone report that yet).
>
> On Wed, Jul 27, 2016 at 7:12 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Even running cluster up as root the router can't bind to ports 80 and
>> 443.
>>
>> On Wed, 27 Jul 2016 at 9:52 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> Don't think so.
>>>
>>> $ sudo netstat -tulpn
>>> Active Internet connections (only servers)
>>> Proto Recv-Q Send-Q Local Address   Foreign Address
>>> State   PID/Program name
>>> tcp0  0 104.236.65.18:530.0.0.0:*
>>> LISTEN  1268/openshift
>>> tcp0  0 0.0.0.0:80530.0.0.0:*
>>> LISTEN  1268/openshift
>>> tcp0  0 0.0.0.0:22  0.0.0.0:*
>>> LISTEN  776/sshd
>>> tcp0  0 0.0.0.0:84430.0.0.0:*
>>> LISTEN  1268/openshift
>>> tcp6   0  0 :::4001 :::*
>>>  LISTEN  1268/openshift
>>> tcp6   0  0 :::2376 :::*
>>>  LISTEN  595/docker
>>> tcp6   0  0 :::10250:::*
>>>  LISTEN  1268/openshift
>>> tcp6   0  0 :::22   :::*
>>>  LISTEN  776/sshd
>>> tcp6   0  0 :::7001 :::*
>>>  LISTEN  1268/openshift
>>> udp0  0 0.0.0.0:80530.0.0.0:*
>>> 1268/openshift
>>> udp0  0 104.236.65.18:530.0.0.0:*
>>> 1268/openshift
>>>
>>> But the pod was unable to bind to those ports for some reason.
>>>
>>> $ oc logs -f pod/router-1-y5prn
>>> I0727 11:45:41.395016   1 router.go:161] Router is including routes
>>> in all namespaces
>>> E0727 11:45:41.493170   1 ratelimiter.go:50] error reloading router:
>>> exit status 1
>>> [ALERT] 208/114541 (30) : Starting frontend public: cannot bind socket [
>>> 0.0.0.0:80]
>>> [ALERT] 208/114541 (30) : Starting frontend public_ssl: cannot bind
>>> socket [0.0.0.0:443]
>>>
>>>
>>> On 27 July 2016 at 21:21, Clayton Coleman <ccole...@redhat.com> wrote:
>>>
>>>> Is anything already listening on port 80/443/1936 on your host?  Did
>>>> the router pod get created successfully (oc get pods -n default)?
>>>>
>>>>
>>>>
>>>> On Jul 27, 2016, at 7:12 AM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>> My  iptables has these rules. Is this normal?
>>>>
>>>> Chain KUBE-SERVICES (1 references)
>>>> target prot opt source   destination
>>>> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
>>>> default/router:80-tcp has no endpoints */ tcp dpt:80 reject-with
>>>> icmp-port-unreachable
>>>> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
>>>> default/router:443-tcp has no endpoints */ tcp dpt:443 reject-with
>>>> icmp-port-unreachable
>>>> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
>>>> default/router:1936-tcp has no endpoints */ tcp dpt:1936 reject-with
>>>> icmp-port-unreachable
>>>>
>>>>
>>>> On 27 July 2016 at 16:08, Lionel Orellana <lione...@gmail.com> wrote:
>>>>
>>>>> Further info
>>>>>
>>>>> $ oc get endpoints --namespace=default --selector=router
>>>>>
>>>>> NAME ENDPOINTS AGE
>>>>> router  1h
>>>>>
>>>>> Router has no endpoints?
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 27 Jul 2016 at 3:22 PM, Lionel Orellana <lione...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Forgot to mention
>>>>>>
>>>>>> Openshift v1.3.0-alpha.2
>>>>>> Docker 1.11.2
>>>>>> Ubuntu 15.10
>>>>>>
>

Re: oc cluster up - dns issue?

2016-07-27 Thread Lionel Orellana
Even running cluster up as root the router can't bind to ports 80 and 443.

On Wed, 27 Jul 2016 at 9:52 PM, Lionel Orellana <lione...@gmail.com> wrote:

> Don't think so.
>
> $ sudo netstat -tulpn
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address State
>   PID/Program name
> tcp0  0 104.236.65.18:530.0.0.0:*
> LISTEN  1268/openshift
> tcp0  0 0.0.0.0:80530.0.0.0:*
> LISTEN  1268/openshift
> tcp0  0 0.0.0.0:22  0.0.0.0:*
> LISTEN  776/sshd
> tcp0  0 0.0.0.0:84430.0.0.0:*
> LISTEN  1268/openshift
> tcp6   0  0 :::4001 :::*LISTEN
>  1268/openshift
> tcp6   0  0 :::2376 :::*LISTEN
>  595/docker
> tcp6   0  0 :::10250:::*LISTEN
>  1268/openshift
> tcp6   0  0 :::22   :::*LISTEN
>  776/sshd
> tcp6   0  0 :::7001 :::*LISTEN
>  1268/openshift
> udp0  0 0.0.0.0:80530.0.0.0:*
>   1268/openshift
> udp0  0 104.236.65.18:530.0.0.0:*
>   1268/openshift
>
> But the pod was unable to bind to those ports for some reason.
>
> $ oc logs -f pod/router-1-y5prn
> I0727 11:45:41.395016   1 router.go:161] Router is including routes in
> all namespaces
> E0727 11:45:41.493170   1 ratelimiter.go:50] error reloading router:
> exit status 1
> [ALERT] 208/114541 (30) : Starting frontend public: cannot bind socket [
> 0.0.0.0:80]
> [ALERT] 208/114541 (30) : Starting frontend public_ssl: cannot bind socket
> [0.0.0.0:443]
>
>
> On 27 July 2016 at 21:21, Clayton Coleman <ccole...@redhat.com> wrote:
>
>> Is anything already listening on port 80/443/1936 on your host?  Did the
>> router pod get created successfully (oc get pods -n default)?
>>
>>
>>
>> On Jul 27, 2016, at 7:12 AM, Lionel Orellana <lione...@gmail.com> wrote:
>>
>> My  iptables has these rules. Is this normal?
>>
>> Chain KUBE-SERVICES (1 references)
>> target prot opt source   destination
>> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
>> default/router:80-tcp has no endpoints */ tcp dpt:80 reject-with
>> icmp-port-unreachable
>> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
>> default/router:443-tcp has no endpoints */ tcp dpt:443 reject-with
>> icmp-port-unreachable
>> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
>> default/router:1936-tcp has no endpoints */ tcp dpt:1936 reject-with
>> icmp-port-unreachable
>>
>>
>> On 27 July 2016 at 16:08, Lionel Orellana <lione...@gmail.com> wrote:
>>
>>> Further info
>>>
>>> $ oc get endpoints --namespace=default --selector=router
>>>
>>> NAME ENDPOINTS AGE
>>> router  1h
>>>
>>> Router has no endpoints?
>>>
>>>
>>>
>>> On Wed, 27 Jul 2016 at 3:22 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Forgot to mention
>>>>
>>>> Openshift v1.3.0-alpha.2
>>>> Docker 1.11.2
>>>> Ubuntu 15.10
>>>>
>>>> On Wed, 27 Jul 2016 at 3:17 PM, Lionel Orellana <lione...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'm trying the new cluster up command. It seems to run Ok and I can
>>>>> deploy an app (Jenkins, from the template) that also seems to start fine.
>>>>> But I can't hit it. When I go to the url shown in the route chrome says
>>>>> "site can't be reached".
>>>>>
>>>>> If I login to the host I can curl the aplication on the internal
>>>>> ip/port.
>>>>>
>>>>> Seems like a dns issue but I thought xip.io was supposed to take care
>>>>> of that.
>>>>>
>>>>> Do I need to do anything to make my service accessible from outside?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Lionel.
>>>>>
>>>>>
>> ___
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: oc cluster up - dns issue?

2016-07-27 Thread Lionel Orellana
Don't think so.

$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
PID/Program name
tcp0  0 104.236.65.18:530.0.0.0:*   LISTEN
 1268/openshift
tcp0  0 0.0.0.0:80530.0.0.0:*   LISTEN
 1268/openshift
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
 776/sshd
tcp0  0 0.0.0.0:84430.0.0.0:*   LISTEN
 1268/openshift
tcp6   0  0 :::4001 :::*LISTEN
 1268/openshift
tcp6   0  0 :::2376 :::*LISTEN
 595/docker
tcp6   0  0 :::10250:::*LISTEN
 1268/openshift
tcp6   0  0 :::22   :::*LISTEN
 776/sshd
tcp6   0  0 :::7001 :::*LISTEN
 1268/openshift
udp0  0 0.0.0.0:80530.0.0.0:*
1268/openshift
udp0  0 104.236.65.18:530.0.0.0:*
1268/openshift

But the pod was unable to bind to those ports for some reason.

$ oc logs -f pod/router-1-y5prn
I0727 11:45:41.395016   1 router.go:161] Router is including routes in
all namespaces
E0727 11:45:41.493170   1 ratelimiter.go:50] error reloading router:
exit status 1
[ALERT] 208/114541 (30) : Starting frontend public: cannot bind socket [
0.0.0.0:80]
[ALERT] 208/114541 (30) : Starting frontend public_ssl: cannot bind socket [
0.0.0.0:443]


On 27 July 2016 at 21:21, Clayton Coleman <ccole...@redhat.com> wrote:

> Is anything already listening on port 80/443/1936 on your host?  Did the
> router pod get created successfully (oc get pods -n default)?
>
>
>
> On Jul 27, 2016, at 7:12 AM, Lionel Orellana <lione...@gmail.com> wrote:
>
> My  iptables has these rules. Is this normal?
>
> Chain KUBE-SERVICES (1 references)
> target prot opt source   destination
> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
> default/router:80-tcp has no endpoints */ tcp dpt:80 reject-with
> icmp-port-unreachable
> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
> default/router:443-tcp has no endpoints */ tcp dpt:443 reject-with
> icmp-port-unreachable
> REJECT tcp  --  0.0.0.0/0172.30.52.230/*
> default/router:1936-tcp has no endpoints */ tcp dpt:1936 reject-with
> icmp-port-unreachable
>
>
> On 27 July 2016 at 16:08, Lionel Orellana <lione...@gmail.com> wrote:
>
>> Further info
>>
>> $ oc get endpoints --namespace=default --selector=router
>>
>> NAME ENDPOINTS AGE
>> router  1h
>>
>> Router has no endpoints?
>>
>>
>>
>> On Wed, 27 Jul 2016 at 3:22 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> Forgot to mention
>>>
>>> Openshift v1.3.0-alpha.2
>>> Docker 1.11.2
>>> Ubuntu 15.10
>>>
>>> On Wed, 27 Jul 2016 at 3:17 PM, Lionel Orellana <lione...@gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> I'm trying the new cluster up command. It seems to run Ok and I can
>>>> deploy an app (Jenkins, from the template) that also seems to start fine.
>>>> But I can't hit it. When I go to the url shown in the route chrome says
>>>> "site can't be reached".
>>>>
>>>> If I login to the host I can curl the aplication on the internal
>>>> ip/port.
>>>>
>>>> Seems like a dns issue but I thought xip.io was supposed to take care
>>>> of that.
>>>>
>>>> Do I need to do anything to make my service accessible from outside?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Lionel.
>>>>
>>>>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


Re: oc cluster up - dns issue?

2016-07-27 Thread Lionel Orellana
My  iptables has these rules. Is this normal?

Chain KUBE-SERVICES (1 references)
target prot opt source   destination
REJECT tcp  --  0.0.0.0/0172.30.52.230/*
default/router:80-tcp has no endpoints */ tcp dpt:80 reject-with
icmp-port-unreachable
REJECT tcp  --  0.0.0.0/0172.30.52.230/*
default/router:443-tcp has no endpoints */ tcp dpt:443 reject-with
icmp-port-unreachable
REJECT tcp  --  0.0.0.0/0172.30.52.230/*
default/router:1936-tcp has no endpoints */ tcp dpt:1936 reject-with
icmp-port-unreachable


On 27 July 2016 at 16:08, Lionel Orellana <lione...@gmail.com> wrote:

> Further info
>
> $ oc get endpoints --namespace=default --selector=router
>
> NAME ENDPOINTS AGE
> router  1h
>
> Router has no endpoints?
>
>
>
> On Wed, 27 Jul 2016 at 3:22 PM, Lionel Orellana <lione...@gmail.com>
> wrote:
>
>> Forgot to mention
>>
>> Openshift v1.3.0-alpha.2
>> Docker 1.11.2
>> Ubuntu 15.10
>>
>> On Wed, 27 Jul 2016 at 3:17 PM, Lionel Orellana <lione...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> I'm trying the new cluster up command. It seems to run Ok and I can
>>> deploy an app (Jenkins, from the template) that also seems to start fine.
>>> But I can't hit it. When I go to the url shown in the route chrome says
>>> "site can't be reached".
>>>
>>> If I login to the host I can curl the aplication on the internal ip/port.
>>>
>>> Seems like a dns issue but I thought xip.io was supposed to take care
>>> of that.
>>>
>>> Do I need to do anything to make my service accessible from outside?
>>>
>>> Thanks
>>>
>>>
>>> Lionel.
>>>
>>>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


  1   2   >