sonata-nfv / son-mano-framework Goto Github PK

Simple tool to mange the platform

• list plugins
• show plugin status
• force deletion/deregistration of plugins

Currently the external port of son-catalogue-repo is 4002 but the communication is internal if we set the container name. The env variables nsr and vrfr are not taking into account the port just the base URL.

https://github.com/sonata-nfv/son-mano-framework/blob/master/plugins/son-mano-service-lifecycle-management/son_mano_slm/slm_topics.py#L111

Can we take into account the port as well?

There are some points in message.py that do not allow content-type: application/yaml instead of json.

e.g. asnyc call return messages.

This should be improved to support both: JSON (default), YAML (as option).

The objective is to introduce the Function lifecycle manager. The biggest dependency here is whether the IA will be able to support the new workflow by the end of 2016. To be discussed with @DarioValocchi in the second part of november.

http://wiki.sonata-nfv.eu/index.php/Function_Lifecycle_Manager_year2

A test to rule them all :)

Start all components in an automated fashion.

• service lifecycle manager
• function lifecycle manager
• placement executive

Add:

• setup.py
• Dockerfiles
• Integrate into docker-compose

• integrate a data model for registered plugins (e.g. based on mongoengine)
• improve state management logic

This makes our component configuration more "Docker-ish".

The objective is to extend the MANO framework so that both placement SSMs and scaling FSMs become supported.

http://wiki.sonata-nfv.eu/index.php/PlacementScaling

The objective is to transform the SLM (and the FLM) into taskmanagers to increase flexibility.

http://wiki.sonata-nfv.eu/index.php/Service_Lifecycle_Manager_v2
http://wiki.sonata-nfv.eu/index.php/SLM-FLM-Mistral

When a service is terminated we might want to remove some of its SSMs as well (if they are not needed anymore).

To do so, the executive plugin base class should provide a method to remove SSMs from the system (e.g. delete its Docker image).

TODO: This might have more implications. What if a SSM wants to store persistent data? Might be a starting point for SSM repository discussion. But not urgent for now.

See: http://wiki.sonata-nfv.eu/index.php/Son-mano-base

• also check venv support

Assumption:

• SSM is referenced in package
• SSM descriptor usually points to an Docker image of the SSM
  a) reference URL to Docker image in a remote repository
  b) reference to a Docker image within the package to be imported

See: http://wiki.sonata-nfv.eu/index.php/Son-mano-base

In the simple service deployment flow the SLM will invoke the Infrabstract to translate the NSD to the relevant VIM deployment script , then deploy the service, and will expect a deployment final status response. This API needs to be defined, and its use should be implemented in the SLM.
Derived from:
#23

sonata-nfv/son-sp-infrabstract#2
@smendel @shuaibsiddiqui @tsoenen @vidalenc @DarioValocchi

Hi,

I've just noticed that the response callback of the vnf_unchain method in the slm is IA_termination_response (see here). Shouldn't this be IA_unchain_response ? I believe, in the current implementation IA_unchain_response is never called.

Best regards,
Tobias

Hello!
https://github.com/sonata-nfv/son-mano-framework/blob/master/plugins/son-mano-service-lifecycle-management/son_mano_slm/slm.py

Are these urls hardcoded?

The NSR Repository can be accessed through a RESTful API

NSR_REPOSITORY_URL = "http://api.int.sonata-nfv.eu:4002/records/nsr/"
VNFR_REPOSITORY_URL = "http://api.int.sonata-nfv.eu:4002/records/vnfr/";

Monitoring repository, can be accessed throught a RESTful API

MONITORING_REPOSITORY_URL = "http://sp.int2.sonata-nfv.eu:8000/api/v1/";

the functionality provided by the base plugin implementation should be documented - specially for use in cases similar implementation is required in other languages than Python.

• we need some API extension for the SLM, e.g., allow to set custom corr_ids for notification messages etc.

all messages should be documented according to the following format
http://wiki.sonata-nfv.eu/index.php/Mano-framework-message-definition-example

According to the discussion in http://wiki.sonata-nfv.eu/index.php/Talk:NS_LifeCycle_Mgr_MSC the mechanism to request the list of active plugins from the request manager should be changed.

The plugin manager should simply broadcast this information every time it changes (e.g. a new plugin connects to the system). All other plugins can subscribe to this message.

Let's open the discussion on this subject.

The integration test between GK and mano-framework should be:

• Deploy a new service (GK - mano-framework )

Based on:
http://wiki.sonata-nfv.eu/index.php/NS_LifeCycle_Mgr_MSC_Simplified

• What infrastructure we need to perform this test? Containers?, Resources?
• What initials conditions will we need for this test? For the GK, for the mano-framework, infrastucture.

Here will be the High Level architecture of this test:
http://wiki.sonata-nfv.eu/index.php/Integration_Test_Deploy_a_new_Service

create a abstract ExecutivePlugin class that inherits BasePlugin

The SLM needs to be updated, so it can handle the new schemas for descriptors and records.

Hi, @tsoenen and @pkarkazis

I'm not sure how the MANO notifies Monitoring when there's a new service instance available... is it a message published on an internal MQ topic? If so, which is the message?

Now that we have the SLA and the Policy Managers, we might reuse the same topic for their further actions...

We need an instance ID, for each requested service instance, which can be used by the Infr.Adptr to inlcude in the deployment request towards the VIM (the stack_name).

The appropriate place to generate an instance ID would be in the SLM, as soon as it receives the request from the Gatekeeper. The SLM can include it in the service.deploy request and the Infra.Adptr will also include it in the response. This instance ID shall also be used for the respective NSR.

• Basic Plugins monitoring information - http://wiki.sonata-nfv.eu/index.php/WP5_KPI-Monitoring_essentials

Base class in son-mano-base that inherits the normal MANO plugin base class but adds additional APIs to control the management (on-board/start/stop/remove) of SSMs (coming in form of Docker containers).

This is about adding the skeletton. The actual functionalities are captured in separated issues:
#92
#93
#94

See: http://wiki.sonata-nfv.eu/index.php/Son-mano-base

The SSM was previously pulled/imported by the on-boarding procedure

Start a SSM given as a Docker container and ensure that it can connect to a given message broker to communicate with the executive plugin.

For now we start the Docker container in the same Docker environment as all the other MANO plugins. BUT: This should be configurable so that we can run SSMs in an isolated Docker environment later.

See: http://wiki.sonata-nfv.eu/index.php/Son-mano-base

• service lifecycle manager
• function lifecycle manager
• placement executive

Let's open the discussion on this subject.

The integration test son-mano-framework | Plugin Management should be:
Add/Remove a plugin
Collect status of the plugin

Based on:
http://wiki.sonata-nfv.eu/index.php/SP_Plugin_Managment

• What infrastructure we need to perform this test? Containers?, Resources?
• What initials conditions will we need for this test? For the mano-framework, infrastucture.

Here will be the High Level architecture of this test:
http://wiki.sonata-nfv.eu/index.php/Integration_Test_Plugin_Management

Until now, only async. calls are supported. We should also add a blocking API.

We can implement this ontop of the async. API by implementing a mechanism to wait until the callback method was called before retuning from the blocking call.

@tsoenen Last PR produced this error in the integration tests. Could you have a look?

https://jenkins.sonata-nfv.eu/job/int-5-mano-plugin-management/188/console

03:00:19 + python test.py http://sp.int3.sonata-nfv.eu:8001
03:00:19 ================================================
03:00:19 BEGIN test.py
03:00:19 [u'e5e8d1c5-a64b-4bb9-89f5-838b58e14ca1']
03:00:19 {u'uuid': u'e5e8d1c5-a64b-4bb9-89f5-838b58e14ca1', u'last_heartbeat_at': u'None', u'registered_at': u'2017-03-18 22:13:49.134000', u'name': u'son-plugin.TestPlugin', u'state': u'REGISTERED', u'version': u'1.0-dev', u'description': None}
03:00:19 Traceback (most recent call last):
03:00:19   File "test.py", line 57, in <module>
03:00:19     main()
03:00:19   File "test.py", line 41, in main
03:00:19     raise BaseException("Test plugin state != RUNNING")
03:00:19 BaseException: Test plugin state != RUNNING
03:00:19 Build step 'Execute shell' marked build as failure

I've noticed that the pluginmanager stops working if it can't connect to rabbitmq.

Is there a way to handle the exception and retry the connection without die?

Example log here:

13:46:01 + docker logs test.pluginmanager
13:46:01 INFO:son-mano-pluginmanger:model:Connected to MongoDB 'sonata-plugin-manager'@mongo:27017
13:46:01 INFO:son-mano-pluginmanger:model:Cleared DB 'sonata-plugin-manager'
13:46:01 INFO:son-mano-pluginmanger:interface:Started management REST interface @ http://0.0.0.0:8001
13:46:01 INFO:son-mano-base:plugin:Starting MANO Plugin: 'son-plugin.SonPluginManager' ...
13:46:01 Traceback (most recent call last):
13:46:01   File "/usr/local/bin/son-mano-pluginmanager", line 11, in <module>
13:46:01     load_entry_point('son-mano-pluginmanager', 'console_scripts', 'son-mano-pluginmanager')()
13:46:01   File "/son-mano-pluginmanager/son_mano_pluginmanager/__main__.py", line 33, in main
13:46:01     pluginmanager.main()
13:46:01   File "/son-mano-pluginmanager/son_mano_pluginmanager/pluginmanager.py", line 212, in main
13:46:01     SonPluginManager()
13:46:01   File "/son-mano-pluginmanager/son_mano_pluginmanager/pluginmanager.py", line 67, in __init__
13:46:01     auto_heartbeat_rate=0)
13:46:01   File "/usr/local/lib/python3.4/site-packages/sonmanobase-0.9-py3.4.egg/sonmanobase/plugin.py", line 82, in __init__
13:46:01   File "/usr/local/lib/python3.4/site-packages/sonmanobase-0.9-py3.4.egg/sonmanobase/messaging.py", line 234, in __init__
13:46:01   File "/usr/local/lib/python3.4/site-packages/sonmanobase-0.9-py3.4.egg/sonmanobase/messaging.py", line 68, in __init__
13:46:01   File "/usr/local/lib/python3.4/site-packages/sonmanobase-0.9-py3.4.egg/sonmanobase/messaging.py", line 79, in setup_connection
13:46:01   File "/usr/local/lib/python3.4/site-packages/AMQPStorm-2.2.2-py3.4.egg/amqpstorm/uri_connection.py", line 46, in __init__
13:46:01   File "/usr/local/lib/python3.4/site-packages/AMQPStorm-2.2.2-py3.4.egg/amqpstorm/connection.py", line 70, in __init__
13:46:01   File "/usr/local/lib/python3.4/site-packages/AMQPStorm-2.2.2-py3.4.egg/amqpstorm/connection.py", line 190, in open
13:46:01   File "/usr/local/lib/python3.4/site-packages/AMQPStorm-2.2.2-py3.4.egg/amqpstorm/io.py", line 100, in open
13:46:01   File "/usr/local/lib/python3.4/site-packages/AMQPStorm-2.2.2-py3.4.egg/amqpstorm/io.py", line 171, in _find_address_and_connect
13:46:01 amqpstorm.exception.AMQPConnectionError: Could not connect to broker:5672

• cleanup
• improve documentation

@mpeuster @mehraghdam @smendel @stevenvanrossem @wtaverni @adrian-rosello @shuaibsiddiqui @DarioValocchi @pkarkazis : Hi all!

Since performing scaling / using SSMs is part of our year1 goal, I tried to make a simplified MSC/workflow that could lead to a first simple implementation: http://wiki.sonata-nfv.eu/index.php/MSC_Kernel_US_Service_Scaling_Simple_First_Iteration#Explanation

Could you go through it and highlight missing links? Especially for the monitoring (the SP side) and the infrastructure adapter, are these suggestions doable, or am I assuming functionality that is not there yet?

To speed up the process on this, we could hold a call somewhere in the next couple of days.

• use e.g. https://hub.docker.com/_/rabbitmq/ for the broker container
• there should be also images for Python environments

This will speed up the build process and reduce the Jenkins load.

Thanks to Felipe for the suggestion.

SSMs should not be based on the normal PluginBase class.

Hi,

The service lifecycle management (SLM) service send a YAML descriptor to the specific manager registry (SMR) about the deployed service and the needed SSMs. The YAML is created at son-mano-framework/plugins/son-mano-service-lifecycle-management/son_mano_slm/slm.py:589 and processed from the son-mano-framework/son-mano-specificmanager/son-mano-specific-manager-registry/son_mano_specific_manager_registry/specificmanagerregistry.py:106 position. It's easy to see that the expected format is not the same as the one that is provided. Which service has an incorrect interface implementation? What is the intended interface (YAML schema?)

Regards,
Janos

The SLM needs to inform the Monitoring Manager when new services are being deployed. The Monitoring Manager must connect to the message broker, to inform the SLM when tresholds in the monitored values are reached.

Can be assigned to me.

The service lifecycle manager plugin: http://wiki.sonata-nfv.eu/index.php/T4.2_%2B_T4.3_Orchestrator_kernel_%2B_Plugins#Deploy_a_Service

There is a empty skeleton for it: https://github.com/sonata-nfv/son-mano-framework/tree/master/plugins/son-mano-service-lifecycle-management

In the simple service deployment flow the following interactions are expected between the SLM and the repositories:

• the SLM is expected to register the eventually running service in the relevant repositories.
  the APIs needs to be defined, and its use should be implemented in the SLM.
• The SLM should verify there are available resources for the service

Derived from:
#23

see also
https://github.com/sonata-nfv/son-sp-repos/issues/3

@shuaibsiddiqui @vidalenc @felipevicens

There is an empty skeleton for it: https://github.com/sonata-nfv/son-mano-framework/tree/master/plugins/son-mano-function-lifecycle-management

• REST API
• What should a platform operator be able to do?
  • PAUSE/UNPAUSE/STOP plugins
  • anything else for first PoC

Define and implement a API for simple service deployment to be used by the GK
Derived from:
#23
see also
sonata-nfv/son-gkeeper#33

@jbonnet @shuaibsiddiqui @tsoenen @mpeuster

The objective is to transform the MANO framework into a scalable and reliable framework. First step is to discuss how we can achieve this for the different elements of the MANO framework.

http://wiki.sonata-nfv.eu/index.php/Scalable_Reliable_Flexible_MANO_framework

For now, I disabled this code, since it was causing issues with the broker. Their seemed to be an issue with the callback_factory method.

I'll give a more clear description next week (this github issue will help me remind it)

There is an empty skeleton: https://github.com/sonata-nfv/son-mano-framework/tree/master/plugins/son-mano-placement