Changing ROUTING_SUFFIX?

[Dave Neary]

Hi,

When I set up OpenShift Origin, I left the default routing suffix
.router.default.svc.cluster.local (figured if it needed changing, I'd
find out sooner or later and be able to change it).

Now I need to change it to have my app work, and I'm unclear what the
best way to do that is - is this a per-project thing, or something that
is set at the OpenShift level? Is it a config file I need to change and
restart Origin, or is this something I dynamically change from the
command line?

I found this page, which talks about changing the option in run-time
with minishift, but I used openshift-ansible, so I'm not sure it I can
do this with oc.
https://docs.openshift.org/latest/minishift/openshift/openshift-client-binary.html

Thanks,
Dave.


-- 
Dave Neary - Open Source and Standards team
Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

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

Re: Prometheus node exporter on v3.7

[Joel Pearson]

Upgrade your cluster to 3.9 just to be safe? You know you want too ... ;)
On Fri, 4 May 2018 at 6:00 am, Tim Dudgeon  wrote:

> Any Prometheus experts out there that can comment on this?
>
>
> On 30/04/18 15:19, Tim Dudgeon wrote:
> > I'm running Prometheus an Origin cluster using v3.7.2 installed from
> > the playbooks on the release-3.7 branch of openshift/openshift-ansible.
> >
> > It looks like the node exported was not included in this version [1]
> > but was added for the 3.9 version [2].
> > As it's metrics on the nodes that I'm wanting most I wonder what the
> > best approach is here.
> >
> > It is safe to run the `playbooks/openshift-prometheus/config.yml`
> > playbook from the release-3.9 branch on a cluster running v3.7.2, or
> > is there a better approach?
> >
> > [1] (v3.7)
> >
> https://github.com/openshift/openshift-ansible/tree/release-3.7/roles/openshift_prometheus/tasks
> > [2] (v3.9)
> >
> https://github.com/openshift/openshift-ansible/tree/release-3.9/roles/openshift_prometheus/tasks
> >
>
> ___
> 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: Prometheus node exporter on v3.7

[Tim Dudgeon]

Any Prometheus experts out there that can comment on this?


On 30/04/18 15:19, Tim Dudgeon wrote:
I'm running Prometheus an Origin cluster using v3.7.2 installed from 
the playbooks on the release-3.7 branch of openshift/openshift-ansible.


It looks like the node exported was not included in this version [1] 
but was added for the 3.9 version [2].
As it's metrics on the nodes that I'm wanting most I wonder what the 
best approach is here.


It is safe to run the `playbooks/openshift-prometheus/config.yml` 
playbook from the release-3.9 branch on a cluster running v3.7.2, or 
is there a better approach?


[1] (v3.7) 
https://github.com/openshift/openshift-ansible/tree/release-3.7/roles/openshift_prometheus/tasks
[2] (v3.9) 
https://github.com/openshift/openshift-ansible/tree/release-3.9/roles/openshift_prometheus/tasks




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

Re: projectRequests in openshift v3.6 using serviceaccount jenkins

[Jordan Liggitt]

By default, service accounts do not have access to request projects.

If you want to grant that permission, it is contained in the
self-provisioner cluster role, which you can grant like this:

oc adm add-cluster-role-to-user self-provisioner
system:serviceaccount::




On Thu, May 3, 2018 at 5:52 AM, jelmer van amen 
wrote:

> p.s
>
> I found that curl -k -H "Authorization: Bearer $TOKEN" -H 'Accept:
> application/json' https://kubernetes.default.
> svc/oapi/v1/projectrequests
>
> Gives a similar result
> {
>   "kind": "Status",
>   "apiVersion": "v1",
>   "metadata": {},
>   "status": "Failure",
>   "message": "You may not request a new project via this API.",
>   "reason": "Forbidden",
>   "details": {
> "group": "project.openshift.io",
> "kind": "projectrequest"
>   },
>   "code": 403
>
> Is there some extra permission needed to call apis with a service account?
>
> On 3 May 2018 at 11:45, jelmer van amen  wrote:
>
>> Hi all,
>>
>> I'm trying to get arquillian-cube working from jenkins. Arquillian cube
>> want's to create new namepsaces to spin up the tests. To do this, it calls
>> curl -k -H "Authorization: Bearer $TOKEN" -H 'Accept:
>> application/json' https://kubernetes.default.sv
>> c/apis/project.openshift.io/v1/projectrequests
>>
>> This returns:
>> {
>>   "kind": "Status",
>>   "apiVersion": "v1",
>>   "metadata": {},
>>   "status": "Failure",
>>   "message": "You may not request a new project via this API.",
>>   "reason": "Forbidden",
>>   "details": {
>> "group": "project.openshift.io",
>> "kind": "projectrequest"
>>   },
>>   "code": 403
>>
>>
>> The service user belonging to the token should have all the rights. I've
>> searched the documentation and the first notice of this specific path is in
>> openshift v3.7. Am I correct in thinking that this api endpoint is not
>> available in openshift v3.6? Or is this still a rights problem?
>>
>> Kind regards,
>> Jelmer
>>
>>
>
> ___
> 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: projectRequests in openshift v3.6 using serviceaccount jenkins

[jelmer van amen]

p.s

I found that curl -k -H "Authorization: Bearer $TOKEN" -H 'Accept:
application/json' https://kubernetes.default.svc/oapi/v1/projectrequests

Gives a similar result
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "You may not request a new project via this API.",
  "reason": "Forbidden",
  "details": {
"group": "project.openshift.io",
"kind": "projectrequest"
  },
  "code": 403

Is there some extra permission needed to call apis with a service account?

On 3 May 2018 at 11:45, jelmer van amen  wrote:

> Hi all,
>
> I'm trying to get arquillian-cube working from jenkins. Arquillian cube
> want's to create new namepsaces to spin up the tests. To do this, it calls
> curl -k -H "Authorization: Bearer $TOKEN" -H 'Accept:
> application/json' https://kubernetes.default.
> svc/apis/project.openshift.io/v1/projectrequests
>
> This returns:
> {
>   "kind": "Status",
>   "apiVersion": "v1",
>   "metadata": {},
>   "status": "Failure",
>   "message": "You may not request a new project via this API.",
>   "reason": "Forbidden",
>   "details": {
> "group": "project.openshift.io",
> "kind": "projectrequest"
>   },
>   "code": 403
>
>
> The service user belonging to the token should have all the rights. I've
> searched the documentation and the first notice of this specific path is in
> openshift v3.7. Am I correct in thinking that this api endpoint is not
> available in openshift v3.6? Or is this still a rights problem?
>
> Kind regards,
> Jelmer
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

projectRequests in openshift v3.6 using serviceaccount jenkins

[jelmer van amen]

Hi all,

I'm trying to get arquillian-cube working from jenkins. Arquillian cube
want's to create new namepsaces to spin up the tests. To do this, it calls
curl -k -H "Authorization: Bearer $TOKEN" -H 'Accept:
application/json'
https://kubernetes.default.svc/apis/project.openshift.io/v1/projectrequests

This returns:
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "You may not request a new project via this API.",
  "reason": "Forbidden",
  "details": {
"group": "project.openshift.io",
"kind": "projectrequest"
  },
  "code": 403


The service user belonging to the token should have all the rights. I've
searched the documentation and the first notice of this specific path is in
openshift v3.7. Am I correct in thinking that this api endpoint is not
available in openshift v3.6? Or is this still a rights problem?

Kind regards,
Jelmer
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users