x
/
gluon
Code Issues Proposed changes

Fix doc gate failure 

This patch set fixes the blocking documentation gate failure for Gluon.

Change-Id: Ic1e1b2ea8c65ba9d29940d1e9034857bfc78d0c6
This commit is contained in:
Tin Lam 2017-05-31 03:00:11 -05:00
parent b82abe1579
commit 5fff618917
8 changed files with 101 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -60,3 +60,6 @@ releasenotes/build
.idea .idea
gluon/gluon.sqlite gluon/gluon.sqlite
gluon/clean.sqlite gluon/clean.sqlite
doc/source/api
doc/source/modules.rst

4
doc/source/devref/database_migration.rst
View File

@ -2,7 +2,6 @@
Database Migration Strategy Database Migration Strategy
=========================== ===========================
-------------------------------
What happens on a model change? What happens on a model change?
------------------------------- -------------------------------
@ -15,8 +14,6 @@ Similar to Neutron migration strategy a script for auto generation is used:
The big difference is that Proton will have a YAML model. So a new The big difference is that Proton will have a YAML model. So a new
auto generate script is needed. auto generate script is needed.
-----------------
Migration Process Migration Process
----------------- -----------------
@ -32,7 +29,6 @@ See details in the devref:
`Neutron Database Migration <http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html>`_ `Neutron Database Migration <http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html>`_
-------
Testing Testing
------- -------

136
doc/source/devref/gluon-auth.rst
View File

@ -28,28 +28,28 @@ If the token is valid, Keystone will retrieve additional information from token
such as user name, user id, project name, project id etc and send this information such as user name, user id, project name, project id etc and send this information
to the OpenStack service. Otherwise, the request will be rejected. to the OpenStack service. Otherwise, the request will be rejected.
Setting up Setting up
~~~~~~~~~~ ~~~~~~~~~~
Once Keystone is installed and running, services have to be configured to work with it. Once Keystone is installed and running, services have to be configured to work with it.
This involves setting up projects, roles, users, and services. By default, OpenStack This involves setting up projects, roles, users, and services. By default, OpenStack
already has several projects, roles and users created. already has several projects, roles and users created.
Following is the normal process to add a service to Keystone. Following is the normal process to add a service to Keystone.
- Create a project - Create a project
- Create a user for the service and add the user to the project - Create a user for the service and add the user to the project
- Create an admin role and assign to the user - Create an admin role and assign to the user
- Create service - Create service
- Create endpoint - Create endpoint
For Gluon, we will add these objects. For Gluon, we will add these objects.
- Create a new user called "gluon" - Create a new user called "gluon"
- Add "gluon" user to "service" project - Add "gluon" user to "service" project
- Add "service" role to "gluon" user in the "service" project - Add "service" role to "gluon" user in the "service" project
- Create a new service called "gluon" - Create a new service called "gluon"
- Create a new endpoint under the service "gluon" - Create a new endpoint under the service "gluon"
Authorization Authorization
------------- -------------
@ -90,25 +90,27 @@ Following will be the default rules:
The actions are defined within the "policies" section as shown below. The actions are defined within the "policies" section as shown below.
ProtonBasePort: .. code-block:: yaml
...
existing model definition ProtonBasePort:
... ...
existing model definition
...
policies: policies:
actions: actions:
create: create:
role: "rule:admin_or_network_owner" role: "rule:admin_or_network_owner"
delete: delete:
role: "rule:admin_or_network_owner" role: "rule:admin_or_network_owner"
get: get:
role: "rule:admin_or_owner" role: "rule:admin_or_owner"
get_one: get_one:
role: "rule:admin_or_owner" role: "rule:admin_or_owner"
update: update:
role: "rule:admin_or_network_owner" role: "rule:admin_or_network_owner"
This policy defines create, delete, get, get_one and update actions on the ProtonBasePort object. This policy defines create, delete, get, get_one and update actions on the ProtonBasePort object.
@ -122,42 +124,44 @@ Converting to policy.json file
During the installation of Gluon, the embedded policies in the YAML model file will be converted During the installation of Gluon, the embedded policies in the YAML model file will be converted
to /etc/gluon/policy.json file. This file will have the following format. to /etc/gluon/policy.json file. This file will have the following format.
{ .. code-block:: json
"context_is_admin": "role:admin or user_name:gluon",
"owner": "tenant_id:%(tenant_id)s",
"admin_or_owner": "rule:context_is_admin or rule:owner",
"context_is_advsvc": "role:advsvc",
"admin_or_network_owner": "rule:context_is_admin or tenant_id:%(network:tenant_id)s",
"admin_owner_or_network_owner": "rule:owner or rule:admin_or_network_owner",
"admin_only": "rule:context_is_admin",
"regular_user": "",
"default": "rule:admin_or_owner",
"create_ports": "rule:admin_or_network_owner", {
"get_ports": "rule:admin_or_owner", "context_is_admin": "role:admin or user_name:gluon",
"update_ports": "rule:admin_or_network_owner", "owner": "tenant_id:%(tenant_id)s",
"delete_ports": "rule:admin_or_network_owner", "admin_or_owner": "rule:context_is_admin or rule:owner",
"context_is_advsvc": "role:advsvc",
"admin_or_network_owner": "rule:context_is_admin or tenant_id:%(network:tenant_id)s",
"admin_owner_or_network_owner": "rule:owner or rule:admin_or_network_owner",
"admin_only": "rule:context_is_admin",
"regular_user": "",
"default": "rule:admin_or_owner",
"create_interfaces": "rule:admin_or_network_owner", "create_ports": "rule:admin_or_network_owner",
"get_interfaces": "rule:admin_or_owner", "get_ports": "rule:admin_or_owner",
"update_interfaces": "rule:admin_or_network_owner", "update_ports": "rule:admin_or_network_owner",
"delete_interfaces": "rule:admin_or_network_owner", "delete_ports": "rule:admin_or_network_owner",
"create_vpns": "rule:admin_or_network_owner", "create_interfaces": "rule:admin_or_network_owner",
"get_vpns": "rule:admin_or_owner", "get_interfaces": "rule:admin_or_owner",
"update_vpns": "rule:admin_or_network_owner", "update_interfaces": "rule:admin_or_network_owner",
"delete_vpns": "rule:admin_or_network_owner", "delete_interfaces": "rule:admin_or_network_owner",
"create_vpnbindings": "rule:admin_or_network_owner", "create_vpns": "rule:admin_or_network_owner",
"get_vpnbindings": "rule:admin_or_owner", "get_vpns": "rule:admin_or_owner",
"update_vpnbindings": "rule:admin_or_network_owner", "update_vpns": "rule:admin_or_network_owner",
"delete_vpnbindings": "rule:admin_or_network_owner", "delete_vpns": "rule:admin_or_network_owner",
"create_vpnafconfigs": "rule:admin_or_network_owner", "create_vpnbindings": "rule:admin_or_network_owner",
"get_vpnafconfigs": "rule:admin_or_owner", "get_vpnbindings": "rule:admin_or_owner",
"update_vpnafconfigs": "rule:admin_or_network_owner", "update_vpnbindings": "rule:admin_or_network_owner",
"delete_vpnafconfigs": "rule:admin_or_network_owner", "delete_vpnbindings": "rule:admin_or_network_owner",
}
"create_vpnafconfigs": "rule:admin_or_network_owner",
"get_vpnafconfigs": "rule:admin_or_owner",
"update_vpnafconfigs": "rule:admin_or_network_owner",
"delete_vpnafconfigs": "rule:admin_or_network_owner",
}
Bootstrapping policy.json Bootstrapping policy.json
@ -180,10 +184,10 @@ with Gluon to add keystone authentication and enforce RBAC policies defined in t
The pecan-wsgi service in the Neutron will be used as a reference code for Gluon implementation The pecan-wsgi service in the Neutron will be used as a reference code for Gluon implementation
Configuration Configuration
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
The /etc/proton/proton.conf file can be used to configure the authentication details. A sample The /etc/proton/proton.conf file can be used to configure the authentication details. A sample
configuration is shown below. configuration is shown below.
[api] [api]
auth_strategy = keystone auth_strategy = keystone

5
doc/source/devref/high_level_design.rst
View File

@ -99,13 +99,14 @@ information from ``etcd``.
The ``ports`` can be viewed using the command: The ``ports`` can be viewed using the command:
.. code-block:: bash .. code-block:: bash
$ protonclient --api net-l3vpn port-list
$ protonclient --api net-l3vpn port-list
More generic command is something like: More generic command is something like:
.. code-block:: bash .. code-block:: bash
# protonclient --api <api-name> [OPTIONS] COMMAND [ARGS] ... # protonclient --api <api-name> [OPTIONS] COMMAND [ARGS] ...
Please refer to **User Guide** [1]_ for more details. Please refer to **User Guide** [1]_ for more details.

2
doc/source/devref/index.rst
View File

@ -32,6 +32,6 @@ Gluon Developer Docs
.. include:: service_binding_model.rst .. include:: service_binding_model.rst
.. include:: database_migration.rst .. include:: database_migration.rst
.. include:: gluon-auth.rst .. include:: gluon-auth.rst
.. include:: gluon-api-spec.rst .. include:: gluon_api_spec.rst
.. include:: gluon_proton_versioning.rst .. include:: gluon_proton_versioning.rst
.. include:: repo_structure.rst .. include:: repo_structure.rst

6
doc/source/devref/service_binding_model.rst
View File

@ -12,7 +12,7 @@ creating new network service APIs. It hence supports developers in making the
best use of the flexibility provided by Gluon. best use of the flexibility provided by Gluon.
This model is based on the "service binding pattern" described in the NetReady This model is based on the "service binding pattern" described in the NetReady
requirements document [1]_ and was adapted for Gluon. requirements document [0]_ and was adapted for Gluon.
The modeling tools in Gluon provide building blocks to allow the creation of The modeling tools in Gluon provide building blocks to allow the creation of
arbitrarily complex networking APIs. However, some constraints are needed to arbitrarily complex networking APIs. However, some constraints are needed to
@ -120,7 +120,7 @@ These are the base objects for defining APIs. These objects cannot be used
directly in an API definition. They must be used as the base object for directly in an API definition. They must be used as the base object for
objects of similar type. There is an **"extends"** keyword in the objects of similar type. There is an **"extends"** keyword in the
YAML model to provide this capability. To have a functional networking API, YAML model to provide this capability. To have a functional networking API,
one must extend the ``BasePort``, ``BaseInterface``, ``BaseService`` and one must extend the ``BasePort``, ``BaseInterface``, ``BaseService`` and
``BaseServiceBinding`` objects. It is not required that additional attributes ``BaseServiceBinding`` objects. It is not required that additional attributes
are defined for the extended objects. See the Interface definition in the are defined for the extended objects. See the Interface definition in the
example_ at the end of this document. example_ at the end of this document.
@ -427,5 +427,5 @@ between these objects and objects extended from base objects.
References References
.. [1] NetReady - Service Binding model: http://artifacts.opnfv.org/netready/colorado/docs/requirements/index.html#service-binding-design-pattern .. [0] NetReady - Service Binding model: http://artifacts.opnfv.org/netready/colorado/docs/requirements/index.html#service-binding-design-pattern

10
doc/source/devref/task_list.rst
View File

@ -43,18 +43,28 @@ For Enhancements of Gluon Implementation
---------------------------------------- ----------------------------------------
#. Investigate how different VIF drivers can be used for different port types on the same hypervisor #. Investigate how different VIF drivers can be used for different port types on the same hypervisor
#. Need to understand VIF plugging and how it affects Gluon #. Need to understand VIF plugging and how it affects Gluon
#. Generic VIF driver may be okay for most use cases #. Generic VIF driver may be okay for most use cases
#. Investigate and resolve synchronization issues in the gluon/proton architecture #. Investigate and resolve synchronization issues in the gluon/proton architecture
#. Need to re-sync proton with gluon upon restart #. Need to re-sync proton with gluon upon restart
#. This is partially done #. This is partially done
#. Synchronization of mysql and etcd databases needs to be investigated #. Synchronization of mysql and etcd databases needs to be investigated
#. Are we covered if Proton restarts or etcd is unavailable for a period of time? #. Are we covered if Proton restarts or etcd is unavailable for a period of time?
#. Synchronize bind operation with SDN controller #. Synchronize bind operation with SDN controller
#. There is no feedback if the SDN bind fails #. There is no feedback if the SDN bind fails
#. Need to make sure bind is done before VM is spawned. Synchronize bind with port_update response #. Need to make sure bind is done before VM is spawned. Synchronize bind with port_update response
#. Binding information needs to be pushed back to Proton #. Binding information needs to be pushed back to Proton
#. Should Proton just read this from etcd? #. Should Proton just read this from etcd?
#. Rebuild Gluon to not use particle generator #. Rebuild Gluon to not use particle generator
------------------------------------ ------------------------------------

22
gluon/api/hooks/context.py
View File

@ -1,17 +1,17 @@
# Copyright 2016 Nokia # Copyright 2016 Nokia
# All Rights Reserved. # All Rights Reserved.
# #
# Licensed under the Apache License, Version 2.0 (the "License"); you may # Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain # not use this file except in compliance with the License. You may obtain
# a copy of the License at # a copy of the License at
# #
# http://www.apache.org/licenses/LICENSE-2.0 # http://www.apache.org/licenses/LICENSE-2.0
# #
# Unless required by applicable law or agreed to in writing, software # Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations # License for the specific language governing permissions and limitations
# under the License. # under the License.
from oslo_middleware import request_id from oslo_middleware import request_id
from pecan import hooks from pecan import hooks