Skip to content

Commit ea050c8

Browse files
detiberChris Houseknecht
authored and
Chris Houseknecht
committed
Update generated client (openshift#10)
* Update scripts and start docs - Updated scripts with latest from client-python - Fix version handling in update script - Add tox envs for docs generation and client generation - Move functional tests out of openshift package to avoid getting deleted. - Various tweaks that need to be upstreamed - Remove some hardcoding of kubernetes/openshift - Updated scripts/pom.xml to use GA swagger-codegen-2.2.2 - python3 fixes for code generation scripts * Update generated client code
1 parent 4691ad3 commit ea050c8

File tree

964 files changed

+2807
-1035
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

964 files changed

+2807
-1035
lines changed

.coveragerc

+2-2
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,8 @@ omit =
55
*/lib/python*/*
66
/usr/*
77
setup.py
8-
conftest.py
9-
openshift/test/*
8+
*/conftest.py
9+
*/test/*
1010

1111
[html]
1212
directory = cover

README.md

+44-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,47 @@
1-
# openshift-restclient-python
1+
# OpenShift python client
22

33
[![Build Status](https://travis-ci.org/openshift/openshift-restclient-python.svg?branch=master)](https://travis-ci.org/openshift/openshift-restclient-python)
44
[![Coverage Status](https://coveralls.io/repos/github/openshift/openshift-restclient-python/badge.svg?branch=master)](https://coveralls.io/github/openshift/openshift-restclient-python?branch=master)
5+
6+
Python client for the [OpenShift](http://openshift.redhat.com/) API.
7+
8+
## Installation
9+
10+
From source:
11+
12+
```
13+
git clone https://github.com/openshift/openshift-restclient-python.git
14+
cd openshift-restclient-python
15+
python setup.py install
16+
```
17+
18+
From [PyPi](https://pypi.python.org/pypi/openshift/) directly (coming soon):
19+
20+
```
21+
pip install openshift
22+
```
23+
24+
## Example
25+
26+
TODO
27+
28+
## Documentation
29+
30+
All APIs and Models' documentation can be found at the [Generated client's README file](openshift/README.md)
31+
32+
## Community, Support, Discussion
33+
34+
If you have any problem with the package or any suggestions, please file an [issue](https://github.com/openshift/openshift-restclient-python/issues).
35+
36+
### Code of Conduct
37+
38+
Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
39+
40+
## Update generated client
41+
Updating the generated client requires the following tools:
42+
- tox
43+
- maven3
44+
45+
1) Incorporate new changes to update scripts
46+
- scripts/constants.py, scripts/pom.xml, scripts/preprocess_spec.py, update-client.sh are the most important
47+
1) Run tox -e update_client

doc/source/conf.py

+82
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
# -*- coding: utf-8 -*-
2+
# Licensed under the Apache License, Version 2.0 (the "License");
3+
# you may not use this file except in compliance with the License.
4+
# You may obtain a copy of the License at
5+
#
6+
# http://www.apache.org/licenses/LICENSE-2.0
7+
#
8+
# Unless required by applicable law or agreed to in writing, software
9+
# distributed under the License is distributed on an "AS IS" BASIS,
10+
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
11+
# implied.
12+
# See the License for the specific language governing permissions and
13+
# limitations under the License.
14+
15+
import os
16+
import sys
17+
18+
from recommonmark.parser import CommonMarkParser
19+
20+
sys.path.insert(0, os.path.abspath('../..'))
21+
# -- General configuration ----------------------------------------------------
22+
23+
source_parsers = {
24+
'.md': CommonMarkParser,
25+
}
26+
27+
source_suffix = ['.rst', '.md']
28+
29+
# Add any Sphinx extension module names here, as strings. They can be
30+
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
31+
extensions = [
32+
'sphinx.ext.autodoc',
33+
# 'sphinx.ext.intersphinx',
34+
]
35+
36+
# autodoc generation is a bit aggressive and a nuisance when doing heavy
37+
# text edit cycles.
38+
# execute "export SPHINX_DEBUG=1" in your terminal to disable
39+
40+
# The suffix of source filenames.
41+
source_suffix = '.rst'
42+
43+
# The master toctree document.
44+
master_doc = 'index'
45+
46+
# General information about the project.
47+
project = u'openshift-restclient-python'
48+
copyright = u'2017, Red Hat, Inc.'
49+
50+
# If true, '()' will be appended to :func: etc. cross-reference text.
51+
add_function_parentheses = True
52+
53+
# If true, the current module name will be prepended to all description
54+
# unit titles (such as .. function::).
55+
add_module_names = True
56+
57+
# The name of the Pygments (syntax highlighting) style to use.
58+
pygments_style = 'sphinx'
59+
60+
# -- Options for HTML output --------------------------------------------------
61+
62+
# The theme to use for HTML and HTML Help pages. Major themes that come with
63+
# Sphinx are currently 'default' and 'sphinxdoc'.
64+
# html_theme_path = ["."]
65+
# html_theme = '_theme'
66+
# html_static_path = ['static']
67+
68+
# Output file base name for HTML help builder.
69+
htmlhelp_basename = '%sdoc' % project
70+
71+
# Grouping the document tree into LaTeX files. List of tuples
72+
# (source start file, target name, title, author, documentclass
73+
# [howto/manual]).
74+
latex_documents = [
75+
('index',
76+
'%s.tex' % project,
77+
u'%s Documentation' % project,
78+
u'OpenShift', 'manual'),
79+
]
80+
81+
# Example configuration for intersphinx: refer to the Python standard library.
82+
# intersphinx_mapping = {'http://docs.python.org/': None}

doc/source/contributing.rst

+5
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
============
2+
Contributing
3+
============
4+
5+
TODO

doc/source/index.rst

+26
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
.. openshift-restclient-python documentation master file, created by
2+
sphinx-quickstart on Tue Jul 9 22:26:36 2013.
3+
You can adapt this file completely to your liking, but it should at least
4+
contain the root `toctree` directive.
5+
6+
Welcome to openshift-restclient-python's documentation!
7+
========================================================
8+
9+
Contents:
10+
11+
.. toctree::
12+
:maxdepth: 2
13+
14+
readme
15+
installation
16+
usage
17+
modules
18+
contributing
19+
20+
Indices and tables
21+
==================
22+
23+
* :ref:`genindex`
24+
* :ref:`modindex`
25+
* :ref:`search`
26+

doc/source/installation.rst

+12
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
============
2+
Installation
3+
============
4+
5+
At the command line::
6+
7+
$ pip install openshift
8+
9+
Or, if you have virtualenvwrapper installed::
10+
11+
$ mkvirtualenv openshift
12+
$ pip install openshift

doc/source/modules.rst

+7
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
openshift
2+
==========
3+
4+
.. toctree::
5+
:maxdepth: 4
6+
7+
openshift

doc/source/readme.rst

+4
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
======
2+
Readme
3+
======
4+
.. include:: ../../README.md

doc/source/usage.rst

+7
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
========
2+
Usage
3+
========
4+
5+
To use openshift-restclient-python in a project::
6+
7+
import openshift

openshift/README.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ OpenShift provides builds, application lifecycle, image content management, and
33

44
This Python package is automatically generated by the [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) project:
55

6-
- API version: v1.5.0-alpha1
6+
- API version: v1.5.0-alpha3
77
- Package version: 1.0.0-snapshot
88
- Build package: io.swagger.codegen.languages.PythonClientCodegen
99

@@ -17,9 +17,9 @@ Python 2.7 and 3.4+
1717
If the python package is hosted on Github, you can install directly from Github
1818

1919
```sh
20-
pip install git+https://github.com/ftl-toolbox/python-openshift.git
20+
pip install git+https://github.com/openshift/openshift-restclient-python.git
2121
```
22-
(you may need to run `pip` with root permission: `sudo pip install git+https://github.com/ftl-toolbox/python-openshift.git`)
22+
(you may need to run `pip` with root permission: `sudo pip install git+https://github.com/openshift/openshift-restclient-python.git`)
2323

2424
Then import the package:
2525
```python

openshift/client/__init__.py

+1-1
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
66
OpenShift provides builds, application lifecycle, image content management, and administrative policy on top of Kubernetes. The API allows consistent management of those objects. All API operations are authenticated via an Authorization bearer token that is provided for service accounts as a generated secret (in JWT form) or via the native OAuth endpoint located at /oauth/authorize. Core infrastructure components may use client certificates that require no authentication. All API operations return a 'resourceVersion' string that represents the version of the object in the underlying storage. The standard LIST operation performs a snapshot read of the underlying objects, returning a resourceVersion representing a consistent version of the listed objects. The WATCH operation allows all updates to a set of objects after the provided resourceVersion to be observed by a client. By listing and beginning a watch from the returned resourceVersion, clients may observe a consistent view of the state of one or more objects. Note that WATCH always returns the update after the provided resourceVersion. Watch may be extended a limited time in the past - using etcd 2 the watch window is 1000 events (which on a large cluster may only be a few tens of seconds) so clients must explicitly handle the \"watch to old error\" by re-listing. Objects are divided into two rough categories - those that have a lifecycle and must reflect the state of the cluster, and those that have no state. Objects with lifecycle typically have three main sections: * 'metadata' common to all objects * a 'spec' that represents the desired state * a 'status' that represents how much of the desired state is reflected on the cluster at the current time Objects that have no state have 'metadata' but may lack a 'spec' or 'status' section. Objects are divided into those that are namespace scoped (only exist inside of a namespace) and those that are cluster scoped (exist outside of a namespace). A namespace scoped resource will be deleted when the namespace is deleted and cannot be created if the namespace has not yet been created or is in the process of deletion. Cluster scoped resources are typically only accessible to admins - resources like nodes, persistent volumes, and cluster policy. All objects have a schema that is a combination of the 'kind' and 'apiVersion' fields. This schema is additive only for any given version - no backwards incompatible changes are allowed without incrementing the apiVersion. The server will return and accept a number of standard responses that share a common schema - for instance, the common error type is 'unversioned.Status' (described below) and will be returned on any error from the API server. The API is available in multiple serialization formats - the default is JSON (Accept: application/json and Content-Type: application/json) but clients may also use YAML (application/yaml) or the native Protobuf schema (application/vnd.kubernetes.protobuf). Note that the format of the WATCH API call is slightly different - for JSON it returns newline delimited objects while for Protobuf it returns length-delimited frames (4 bytes in network-order) that contain a 'versioned.Watch' Protobuf object. See the OpenShift documentation at https://docs.openshift.org for more information.
77
8-
OpenAPI spec version: v1.5.0-alpha1
8+
OpenAPI spec version: v1.5.0-alpha3
99
1010
Generated by: https://github.com/swagger-api/swagger-codegen.git
1111
"""

openshift/client/apis/apis_api.py

+1-1
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
66
OpenShift provides builds, application lifecycle, image content management, and administrative policy on top of Kubernetes. The API allows consistent management of those objects. All API operations are authenticated via an Authorization bearer token that is provided for service accounts as a generated secret (in JWT form) or via the native OAuth endpoint located at /oauth/authorize. Core infrastructure components may use client certificates that require no authentication. All API operations return a 'resourceVersion' string that represents the version of the object in the underlying storage. The standard LIST operation performs a snapshot read of the underlying objects, returning a resourceVersion representing a consistent version of the listed objects. The WATCH operation allows all updates to a set of objects after the provided resourceVersion to be observed by a client. By listing and beginning a watch from the returned resourceVersion, clients may observe a consistent view of the state of one or more objects. Note that WATCH always returns the update after the provided resourceVersion. Watch may be extended a limited time in the past - using etcd 2 the watch window is 1000 events (which on a large cluster may only be a few tens of seconds) so clients must explicitly handle the \"watch to old error\" by re-listing. Objects are divided into two rough categories - those that have a lifecycle and must reflect the state of the cluster, and those that have no state. Objects with lifecycle typically have three main sections: * 'metadata' common to all objects * a 'spec' that represents the desired state * a 'status' that represents how much of the desired state is reflected on the cluster at the current time Objects that have no state have 'metadata' but may lack a 'spec' or 'status' section. Objects are divided into those that are namespace scoped (only exist inside of a namespace) and those that are cluster scoped (exist outside of a namespace). A namespace scoped resource will be deleted when the namespace is deleted and cannot be created if the namespace has not yet been created or is in the process of deletion. Cluster scoped resources are typically only accessible to admins - resources like nodes, persistent volumes, and cluster policy. All objects have a schema that is a combination of the 'kind' and 'apiVersion' fields. This schema is additive only for any given version - no backwards incompatible changes are allowed without incrementing the apiVersion. The server will return and accept a number of standard responses that share a common schema - for instance, the common error type is 'unversioned.Status' (described below) and will be returned on any error from the API server. The API is available in multiple serialization formats - the default is JSON (Accept: application/json and Content-Type: application/json) but clients may also use YAML (application/yaml) or the native Protobuf schema (application/vnd.kubernetes.protobuf). Note that the format of the WATCH API call is slightly different - for JSON it returns newline delimited objects while for Protobuf it returns length-delimited frames (4 bytes in network-order) that contain a 'versioned.Watch' Protobuf object. See the OpenShift documentation at https://docs.openshift.org for more information.
77
8-
OpenAPI spec version: v1.5.0-alpha1
8+
OpenAPI spec version: v1.5.0-alpha3
99
1010
Generated by: https://github.com/swagger-api/swagger-codegen.git
1111
"""

openshift/client/apis/apps_api.py

+1-1
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
66
OpenShift provides builds, application lifecycle, image content management, and administrative policy on top of Kubernetes. The API allows consistent management of those objects. All API operations are authenticated via an Authorization bearer token that is provided for service accounts as a generated secret (in JWT form) or via the native OAuth endpoint located at /oauth/authorize. Core infrastructure components may use client certificates that require no authentication. All API operations return a 'resourceVersion' string that represents the version of the object in the underlying storage. The standard LIST operation performs a snapshot read of the underlying objects, returning a resourceVersion representing a consistent version of the listed objects. The WATCH operation allows all updates to a set of objects after the provided resourceVersion to be observed by a client. By listing and beginning a watch from the returned resourceVersion, clients may observe a consistent view of the state of one or more objects. Note that WATCH always returns the update after the provided resourceVersion. Watch may be extended a limited time in the past - using etcd 2 the watch window is 1000 events (which on a large cluster may only be a few tens of seconds) so clients must explicitly handle the \"watch to old error\" by re-listing. Objects are divided into two rough categories - those that have a lifecycle and must reflect the state of the cluster, and those that have no state. Objects with lifecycle typically have three main sections: * 'metadata' common to all objects * a 'spec' that represents the desired state * a 'status' that represents how much of the desired state is reflected on the cluster at the current time Objects that have no state have 'metadata' but may lack a 'spec' or 'status' section. Objects are divided into those that are namespace scoped (only exist inside of a namespace) and those that are cluster scoped (exist outside of a namespace). A namespace scoped resource will be deleted when the namespace is deleted and cannot be created if the namespace has not yet been created or is in the process of deletion. Cluster scoped resources are typically only accessible to admins - resources like nodes, persistent volumes, and cluster policy. All objects have a schema that is a combination of the 'kind' and 'apiVersion' fields. This schema is additive only for any given version - no backwards incompatible changes are allowed without incrementing the apiVersion. The server will return and accept a number of standard responses that share a common schema - for instance, the common error type is 'unversioned.Status' (described below) and will be returned on any error from the API server. The API is available in multiple serialization formats - the default is JSON (Accept: application/json and Content-Type: application/json) but clients may also use YAML (application/yaml) or the native Protobuf schema (application/vnd.kubernetes.protobuf). Note that the format of the WATCH API call is slightly different - for JSON it returns newline delimited objects while for Protobuf it returns length-delimited frames (4 bytes in network-order) that contain a 'versioned.Watch' Protobuf object. See the OpenShift documentation at https://docs.openshift.org for more information.
77
8-
OpenAPI spec version: v1.5.0-alpha1
8+
OpenAPI spec version: v1.5.0-alpha3
99
1010
Generated by: https://github.com/swagger-api/swagger-codegen.git
1111
"""

0 commit comments

Comments
 (0)