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
gluon/gluon.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
===========================
-------------------------------
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
auto generate script is needed.
-----------------
Migration Process
-----------------
@ -32,7 +29,6 @@ See details in the devref:
`Neutron Database Migration <http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html>`_
-------
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
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.
This involves setting up projects, roles, users, and services. By default, OpenStack
already has several projects, roles and users created.
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
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 user for the service and add the user to the project
- Create an admin role and assign to the user
- Create service
- Create endpoint
- Create a project
- Create a user for the service and add the user to the project
- Create an admin role and assign to the user
- Create service
- Create endpoint
For Gluon, we will add these objects.
For Gluon, we will add these objects.
- Create a new user called "gluon"
- Add "gluon" user to "service" project
- Add "service" role to "gluon" user in the "service" project
- Create a new service called "gluon"
- Create a new endpoint under the service "gluon"
- Create a new user called "gluon"
- Add "gluon" user to "service" project
- Add "service" role to "gluon" user in the "service" project
- Create a new service called "gluon"
- Create a new endpoint under the service "gluon"
Authorization
-------------
@ -90,25 +90,27 @@ Following will be the default rules:
The actions are defined within the "policies" section as shown below.
ProtonBasePort:
...
existing model definition
...
.. code-block:: yaml
ProtonBasePort:
...
existing model definition
...
policies:
policies:
actions:
create:
role: "rule:admin_or_network_owner"
delete:
role: "rule:admin_or_network_owner"
get:
role: "rule:admin_or_owner"
get_one:
role: "rule:admin_or_owner"
update:
role: "rule:admin_or_network_owner"
actions:
create:
role: "rule:admin_or_network_owner"
delete:
role: "rule:admin_or_network_owner"
get:
role: "rule:admin_or_owner"
get_one:
role: "rule:admin_or_owner"
update:
role: "rule:admin_or_network_owner"
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
to /etc/gluon/policy.json file. This file will have the following format.
{
"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",
.. code-block:: json
"create_ports": "rule:admin_or_network_owner",
"get_ports": "rule:admin_or_owner",
"update_ports": "rule:admin_or_network_owner",
"delete_ports": "rule:admin_or_network_owner",
{
"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_interfaces": "rule:admin_or_network_owner",
"get_interfaces": "rule:admin_or_owner",
"update_interfaces": "rule:admin_or_network_owner",
"delete_interfaces": "rule:admin_or_network_owner",
"create_ports": "rule:admin_or_network_owner",
"get_ports": "rule:admin_or_owner",
"update_ports": "rule:admin_or_network_owner",
"delete_ports": "rule:admin_or_network_owner",
"create_vpns": "rule:admin_or_network_owner",
"get_vpns": "rule:admin_or_owner",
"update_vpns": "rule:admin_or_network_owner",
"delete_vpns": "rule:admin_or_network_owner",
"create_interfaces": "rule:admin_or_network_owner",
"get_interfaces": "rule:admin_or_owner",
"update_interfaces": "rule:admin_or_network_owner",
"delete_interfaces": "rule:admin_or_network_owner",
"create_vpnbindings": "rule:admin_or_network_owner",
"get_vpnbindings": "rule:admin_or_owner",
"update_vpnbindings": "rule:admin_or_network_owner",
"delete_vpnbindings": "rule:admin_or_network_owner",
"create_vpns": "rule:admin_or_network_owner",
"get_vpns": "rule:admin_or_owner",
"update_vpns": "rule:admin_or_network_owner",
"delete_vpns": "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",
}
"create_vpnbindings": "rule:admin_or_network_owner",
"get_vpnbindings": "rule:admin_or_owner",
"update_vpnbindings": "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
@ -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
Configuration
Configuration
~~~~~~~~~~~~~
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]
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:
.. code-block:: bash
$ protonclient --api net-l3vpn port-list
$ protonclient --api net-l3vpn port-list
More generic command is something like:
.. 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.

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

@ -32,6 +32,6 @@ Gluon Developer Docs
.. include:: service_binding_model.rst
.. include:: database_migration.rst
.. include:: gluon-auth.rst
.. include:: gluon-api-spec.rst
.. include:: gluon_api_spec.rst
.. include:: gluon_proton_versioning.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.
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
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
objects of similar type. There is an **"extends"** keyword in the
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
are defined for the extended objects. See the Interface definition in the
example_ at the end of this document.
@ -427,5 +427,5 @@ between these objects and objects extended from base objects.
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
#. Need to understand VIF plugging and how it affects Gluon
#. Generic VIF driver may be okay for most use cases
#. Investigate and resolve synchronization issues in the gluon/proton architecture
#. Need to re-sync proton with gluon upon restart
#. This is partially done
#. 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?
#. Synchronize bind operation with SDN controller
#. 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
#. Binding information needs to be pushed back to Proton
#. Should Proton just read this from etcd?
#. Rebuild Gluon to not use particle generator
------------------------------------

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

@ -1,17 +1,17 @@
# Copyright 2016 Nokia
# All Rights Reserved.
# Copyright 2016 Nokia
# All Rights Reserved.
#
# 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
# a copy of the License at
# 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
# 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
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
from oslo_middleware import request_id
from pecan import hooks