diff --git a/.gitignore b/.gitignore index b97e8d1..6a06050 100644 --- a/.gitignore +++ b/.gitignore @@ -60,3 +60,6 @@ releasenotes/build .idea gluon/gluon.sqlite gluon/clean.sqlite + +doc/source/api +doc/source/modules.rst diff --git a/doc/source/devref/database_migration.rst b/doc/source/devref/database_migration.rst index 694600b..91ce3d2 100644 --- a/doc/source/devref/database_migration.rst +++ b/doc/source/devref/database_migration.rst @@ -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 `_ -------- Testing ------- diff --git a/doc/source/devref/gluon-auth.rst b/doc/source/devref/gluon-auth.rst index 4810eab..efd30e0 100644 --- a/doc/source/devref/gluon-auth.rst +++ b/doc/source/devref/gluon-auth.rst @@ -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 diff --git a/doc/source/devref/high_level_design.rst b/doc/source/devref/high_level_design.rst index c360810..3626353 100644 --- a/doc/source/devref/high_level_design.rst +++ b/doc/source/devref/high_level_design.rst @@ -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 [OPTIONS] COMMAND [ARGS] ... + # protonclient --api [OPTIONS] COMMAND [ARGS] ... Please refer to **User Guide** [1]_ for more details. diff --git a/doc/source/devref/index.rst b/doc/source/devref/index.rst index d8e6b32..417f0b6 100644 --- a/doc/source/devref/index.rst +++ b/doc/source/devref/index.rst @@ -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 diff --git a/doc/source/devref/service_binding_model.rst b/doc/source/devref/service_binding_model.rst index 893d634..c406449 100644 --- a/doc/source/devref/service_binding_model.rst +++ b/doc/source/devref/service_binding_model.rst @@ -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 diff --git a/doc/source/devref/task_list.rst b/doc/source/devref/task_list.rst index 44f35c6..511fb4d 100644 --- a/doc/source/devref/task_list.rst +++ b/doc/source/devref/task_list.rst @@ -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 ------------------------------------ diff --git a/gluon/api/hooks/context.py b/gluon/api/hooks/context.py index 8ac5901..81aaf86 100644 --- a/gluon/api/hooks/context.py +++ b/gluon/api/hooks/context.py @@ -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