Re: LTS release?

[Graham Dumpleton]

Are you expecting this in OpenShift Origin itself?

The RHEL equivalent of upstream OpenShift Origin is OpenShift Container 
Platform.

https://www.openshift.com/products/container-platform/ 


As with RHEL, you get it via a subscription from Red Hat.

You would need to talk with someone appropriate in Red Hat about current 
support lifecycle as I don't know the specific details.

> On 4 Jul 2018, at 5:27 am, Hetz Ben Hamo  wrote:
> 
> Hi,
> 
> Few of my customers are following the OpenShift releases and changes and many 
> of them asked me the same question: They want an implementation that will 
> hold for 1-2 years (just like RHEL) so they (and me) wonder: Will/is there an 
> LTS release for OpenShift?
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

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

Re: Unpredictable oc binary path for Origin version v3.7.0

[Graham Dumpleton]

Personally I would have had a GitHub repo under Minishift org which had just an 
index file in it keyed by versions which are known to work and can be used. 
Minishift could then pull down the index file, get the URL for where binary is, 
which could be anywhere, and then fetch it from there.

Yes it means the index file has to be updated, but being a separate repo that 
doesn't need a new Minishift release and could be done at any time.

This would also solve problem of GitHub API rate limiting when Minishift is 
behind a corporate fire wall, something that I believe was affecting the 
Minishift developers themselves early on. Not sure if workaround for that was 
worked out.

So as is always the case, a level of indirection solves all problems.

Graham

> On 30 Nov 2017, at 6:43 pm, Jean-Francois Maury  wrote:
> 
> Could be doable through the Github API but since 3.7.0 seems binary are not 
> hosted anymore on Github
> 
> On Thu, Nov 30, 2017 at 8:04 AM, Lalatendu Mohanty  > wrote:
> Hi,
> 
> Till v3.7.0-rc.0 release oc binaries were published in github release page 
> [1] but with 3.7.0 the location has changed and causing minishift start 
> --openshift-version v3.7.0 to fail.
> 
> From Minishift side we can change the code to point it to the new location 
> but the new location is difficult to guess programmatically because It seems 
> to contain a build id "1032" which makes it hard for third parties to 
> determine.
> 
> If we can not predict the location then Minishift users can not use a new 
> version of Origin without code changes in Minishift which is not desirable.
> 
> Filed an github issue on the same : 
> https://github.com/openshift/origin/issues/17527 
> 
> Is this going to be the normal going forward? Is there a way to predict the 
> oc binary path from Origin version? Do you have plan to setup a mirror some 
> place with predictable URL?
> 
> [1] https://github.com/openshift/origin/releases/tag/v3.7.0-rc.0 
> 
> [2] 
> https://gcsweb-ci.svc.ci.openshift.org/gcs/origin-ci-test/branch-logs/origin/v3.7.0/builds/test_branch_origin_cross/1032/artifacts/zips/
>  
> 
> Thanks,
> 
> Lala
> 
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev 
> 
> 
> 
> 
> 
> -- 
> JEFF MAURY
> Red Hat 
> 
>  
> jma...@redhat.com    
> 
>   
>  
> @redhatjobs    redhatjobs 
>    @redhatjobs 
>   
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

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

Re: How could I use oc client to search images in integrated docker-registry?

[Graham Dumpleton]

You can use:

oc get is

to list image streams for images in the registry in your current project.

If you have access to other projects you can use '-n' argument and give the 
name of the project.

Running:

oc get is -n openshift

will list image streams in the default 'openshift' project.

You can use:

oc new-app -L

to list images stream, as well as templates in the current project and the 
default 'openshift' project.

You can use:

oc new-app -S

to search for images amongst image streams in current project, default 
'openshift' project and Docker Hub or other external registry attached with the 
OpenShift cluster.

Graham

> On 13 Nov 2017, at 7:32 pm, Yu Wei  wrote:
> 
> Hi,
> How could I list images pushed into integrated docker-registry?
> Could oc client be used? Or any other options?
> 
> Thanks,
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
> ___
> users mailing list
> us...@lists.openshift.redhat.com 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users 
> 
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: OpenShift Origin v3.7.0-alpha.1 released

[Graham Dumpleton]

> On 31 Aug 2017, at 7:47 am, Clayton Coleman  wrote:
> 
> Release notes are up on GitHub v3.7.0-alpha.1 
>  and the new 
> images have been pushed.
> 
> Of major note - in 3.7 OpenShift RBAC will shift to being a layer on top of 
> Kubernetes RBAC (preserving your existing roles).  Existing APIs will 
> continue to be supported, but unlike 3.6 where Kubernetes RBAC was 
> automatically kept in sync with OpenShift RBAC, starting with 3.7 the 
> canonical source of authorization will be via the Kubernetes RBAC APIs.

Any reason there are two Windows binaries for the client tools.



Graham

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

Re: How could I deploy redis cluster on openshift origin cluster?

[Graham Dumpleton]

See:

https://github.com/sclorg/redis-container 


The image can be found at:

https://hub.docker.com/r/centos/redis-32-centos7/ 


Graham


> On 24 Jul 2017, at 1:26 PM, Yu Wei  wrote:
> 
> Hi,
> I want to deploy redis cluster on openshfit origin cluster.
> Is there any images, deployment that could be used?
> 
> Thanks,
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
> ___
> users mailing list
> us...@lists.openshift.redhat.com 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users 
> 
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: oc says existing project, but not able to use it

[Graham Dumpleton]

> On 5 Jul 2017, at 3:22 AM, Bamacharan Kundu  wrote:
> 
> Hi,
> I am using a setup with openshift origin:v1.2.1, for running builds in
> it. For creating projects in that I use "test-admin" with a password
> with the admin.kubeconfig and ca.crt.
> Before creating a project the script checks if the project is existing,
> if yes then use the same.
> Now oc says a project to be existing. But when it tries to use it, it
> complains about access to the project. As system:admin, I am able to see
> that project to is created.
> 
> I am not able to find out a way to figure out what was the user, who
> created this?

What you can do to work out who created a project is run:

oc get project projectname -o json

This will include metadata about the project:

"metadata": {
"annotations": {
"openshift.io/description": "Initial developer project",
"openshift.io/display-name": "My Project",
"openshift.io/requester": "developer",
"openshift.io/sa.scc.mcs": "s0:c7,c4",
"openshift.io/sa.scc.supplemental-groups": 
"15/1",
"openshift.io/sa.scc.uid-range": "15/1"
},
"creationTimestamp": "2017-07-03T00:10:19Z",
"name": "myproject",

The requester is who created it.

> could someone please point me a way to find out project created by whom?
> 
> Regards
> Bamacharan Kundu
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


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

Re: UI - old interface made it easier to create routes

[Graham Dumpleton]

Refresh the window as it should still be there.

The new UI seems to be having a few issues with updating elements on the pages 
properly from what I have seen.

Graham

- Original Message -
> From: "Dusty Mabe" 
> To: "dev" 
> Sent: Wednesday, October 19, 2016 7:59:31 AM
> Subject: UI - old interface made it easier to create routes
> 
> 
> The old interface (I think Pre origin 1.3) used to have a "create route"
> button
> on the overview page. The new interface buries this one layer deeper, but it
> isn't
> clear where to click initially to get there. See the attached images for
> reference.
> 
> Any thoughts on adding this ease of use back?
> 
> Dusty
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 

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

Re: Possible integration of a new Python library (kubeshift) to the Github repo

[Graham Dumpleton]

- Original Message -
> From: "Maciej Szulik" 
> To: "Graham Dumpleton" 
> Cc: "Charlie Drage" , "dev" 
> 
> Sent: Friday, October 7, 2016 8:19:27 PM
> Subject: Re: Possible integration of a new Python library (kubeshift) to the 
> Github repo
> 
> Personally I'd like to see a combination of the two, so that you can
> smoothly communicate
> with k8s/OpenShift API using raw json (Charlie's part),

Some have recently suggested that you shouldn't bother with a special language 
specific client even for that as you can just use 'oc get --raw'. :-)

> but additionally be
> able to manipulate
> actual objects in python code (Graham's part).
> 
> Other than that kudos to both of the gentlemen.
> 
> Maciej
> 
> 
> On Thu, Oct 6, 2016 at 9:59 PM, Graham Dumpleton 
> wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Charlie Drage" 
> > > To: dev@lists.openshift.redhat.com
> > > Sent: Friday, October 7, 2016 12:18:22 AM
> > > Subject: Possible integration of a new Python library (kubeshift) to
> > the  Github repo
> > >
> > > Hey all,
> > >
> > > I've developed and maintained a Python library for both Kubernetes and
> > > OpenShift.
> > >
> > > The link is here:
> > >
> > > https://github.com/cdrage/kubeshift
> > >
> > > The contributors and I have been quite busy integrating new features as
> > well
> > > as having 100% test coverage in regards to each contribution. Not only
> > that,
> > > but we continue to create documentation as well as a website for the
> > > library: https://cdrage.github.io/kubeshift
> > >
> > > The library communicates 100% through the HTTP API as well as generates
> > > appropriate configurations for communication between the two (using the
> > > Requests python library + proper ssl certs, etc.). Another feature is the
> > > integration of automatically retrieving API credentials (via a login
> > > function) in order to ease setup of communication between the two. More
> > > information can be found on the github repo!
> > >
> > > I noticed that OpenShift has https://github.com/openshift/
> > python-interface
> > > seems to no longer be used / developed on. After Google'ing as well as
> > > searching through GitHub I could not find any other efforts on creating a
> > > Python library for OpenShift.
> >
> > My own efforts in the space can be found at:
> >
> > https://github.com/GrahamDumpleton/openshift3-python-library
> >
> > At this point I had been developing this for my own personal use as when I
> > had mentioned I was working on it on some of the lists the sentiment had
> > been that a purpose built Python client library wasn't required as you
> > could just generate one from the Swagger API. Unfortunately the Swagger API
> > definition had various problems with it and the existing tools for
> > generating a client from the Swagger API for Python didn't yield that great
> > of a result.
> >
> > The intent of the library I wrote was to cover a number of different use
> > cases.
> >
> > 1. Reading and manipulating JSON definitions for resource objects
> > independent of any interaction with the REST API. This provided actual
> > Python classes for resource object types based on the schema rather than
> > fiddling with raw dictionaries.
> > 2. Making calls against the REST API, using (1) to be able to create
> > definitions to be passed, or manipulate results so that they could then be
> > passed in a subsequent call.
> > 3. Provide help in creating complicated deployments involving multiple
> > applications such as databases, front ends etc, with linking via
> > environment variables etc. This was relying on a template system using
> > Jinja2 to generate the starter JSON definitions which would then be
> > consumed by (1) with additional Python helper functions to then do link
> > etc.
> >
> > Items (1) and (2) are done with (3) being in progress.
> >
> > I already own the 'openshift3' name in Python package index (PyPi).
> >
> > Graham
> >
> > > Considering the "Kubeshift" is an extension of the efforts at
> > > https://github.com/openshift/python-interface by implementing a Python
> > > library via the "requests" library. Would the OpenShift org consider
> > merging
> > > efforts and 

Re: Possible integration of a new Python library (kubeshift) to the Github repo

[Graham Dumpleton]

- Original Message -
> From: "Charlie Drage" 
> To: dev@lists.openshift.redhat.com
> Sent: Friday, October 7, 2016 12:18:22 AM
> Subject: Possible integration of a new Python library (kubeshift) to the  
> Github repo
> 
> Hey all,
> 
> I've developed and maintained a Python library for both Kubernetes and
> OpenShift.
> 
> The link is here:
> 
> https://github.com/cdrage/kubeshift
> 
> The contributors and I have been quite busy integrating new features as well
> as having 100% test coverage in regards to each contribution. Not only that,
> but we continue to create documentation as well as a website for the
> library: https://cdrage.github.io/kubeshift
> 
> The library communicates 100% through the HTTP API as well as generates
> appropriate configurations for communication between the two (using the
> Requests python library + proper ssl certs, etc.). Another feature is the
> integration of automatically retrieving API credentials (via a login
> function) in order to ease setup of communication between the two. More
> information can be found on the github repo!
> 
> I noticed that OpenShift has https://github.com/openshift/python-interface
> seems to no longer be used / developed on. After Google'ing as well as
> searching through GitHub I could not find any other efforts on creating a
> Python library for OpenShift.

My own efforts in the space can be found at:

https://github.com/GrahamDumpleton/openshift3-python-library

At this point I had been developing this for my own personal use as when I had 
mentioned I was working on it on some of the lists the sentiment had been that 
a purpose built Python client library wasn't required as you could just 
generate one from the Swagger API. Unfortunately the Swagger API definition had 
various problems with it and the existing tools for generating a client from 
the Swagger API for Python didn't yield that great of a result.

The intent of the library I wrote was to cover a number of different use cases.

1. Reading and manipulating JSON definitions for resource objects independent 
of any interaction with the REST API. This provided actual Python classes for 
resource object types based on the schema rather than fiddling with raw 
dictionaries.
2. Making calls against the REST API, using (1) to be able to create 
definitions to be passed, or manipulate results so that they could then be 
passed in a subsequent call.
3. Provide help in creating complicated deployments involving multiple 
applications such as databases, front ends etc, with linking via environment 
variables etc. This was relying on a template system using Jinja2 to generate 
the starter JSON definitions which would then be consumed by (1) with 
additional Python helper functions to then do link etc.

Items (1) and (2) are done with (3) being in progress.

I already own the 'openshift3' name in Python package index (PyPi).

Graham

> Considering the "Kubeshift" is an extension of the efforts at
> https://github.com/openshift/python-interface by implementing a Python
> library via the "requests" library. Would the OpenShift org consider merging
> efforts and having "kubeshift" integrated into the OpenShift repo as a
> first-class Python library for OpenShift / Kubernetes?
> 
> Of course, I will continue development of said library, but the more eyes on
> it (via the openshift repo) the more feedback we get as well as usage of
> OpenShift :)
> 
> Many thanks!
> 
> Charlie Drage
> PGP - 4096R/C037D617
> http://pgp.mit.edu/pks/lookup?op=get&search=0xDA227403C037D617
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 

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