sonata-nfv / son-sp-infrabstract Goto Github PK

as initial step for year 1 demo we would like to implement a simple deploy service flow.
more details from the MANO framework side can be found here -
sonata-nfv/son-mano-framework#23.

we need to define the required repositories API as the SLM is expected to register the eventually running service in the relevant repositories

Hi,

The IA now supports the Keystone API to fetch all the other endpoints. This works well.

But, it is not possible to specify the port of the Keystone API to use. This one is hardcoded :-(

Couldn't we have a field in the infrastructure.management.compute.add that supports the specification of the vim_port in addition to vim_address? This would really make the IA much more flexible.

Map resource properties from VNFDs e.g. vcpus to Docker containers in emulation.

• vcpus
• cputime
• mem

Service:

Proxy (Squid) --> Http (Apache)

Service should deliver "CatTube" over the proxy so a suer can watch videos.

1 PoP
2 PoPs

In order for the SSM to be able to connect to vms within openstack the IA needs to support security group.
required changes:

• heat client - to support security groups

Implement a new Networking Wrapper to implement SFC based on OpenStack project
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Newton version of OpenStack offers support for defining chain from Heat template
https://specs.openstack.org/openstack/heat-specs/specs/newton/sfc-heat.html

Record as much as possible. We can cut out later. Especially show all the interfaces etc. used to instantiate etc.

• put RAW video material into shared sciebo folder

Setup the new wrapper with a full SP installation and do end-to-end tests.

Hi,

I am currently working towards the SONATA SP to emulator integration and I am not sure if I found a bug in the IA or if this is the correct way to create heat templates.

The possible problem is shown in the code snippets below which show parts of the heat template that is generated by the IA and sent to the VIM.

emulator-socat-vnf.output.net.9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01:
    type: "OS::Neutron::Net"
    properties:
      name: "emulator-socat-vnf.output.net.9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01"

emulator-socat-vnf.output.subnet.9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01:
    type: "OS::Neutron::Subnet"
    properties:
      name: "emulator-socat-vnf.output.subnet.9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01"
      cidr: "172.0.0.64/27"
      dns_nameservers:
      - "8.8.8.8"
      network:
        get_resource: "emulator-socat-vnf.output:net:9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01"

The first snipped defines a OS::Neutron::Net with the name emulator-socat-vnf.output.net.9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01. This looks OK.

The second snipped defines a OS::Neutron::Subnet and tries to reference the network get_resource: "emulator-socat-vnf.output:net:9df6a98f-9e11-4cb7-b3c2-InAdUnitTest-01" and this does not match to the name of the previously defined network!

Problem is the .net. vs. :net: in the name/reference.

Is this really the correct behavior?

How to install?
How to configure build env?
How to execute tests?

i am running below error while running gtk-api.

/app/models/mano_manager_service.rb:34: warning: previous definition of LOG_MESSAGE was here

• Gracefully stopping, waiting for requests to finish
  ! Unable to load application: NoMethodError: undefined method stop' for nil:NilClass bundler: failed to load command: puma (/usr/local/bundle/bin/puma) NoMethodError: undefined method stop' for nil:NilClass
  /usr/local/bundle/gems/puma-3.11.0/lib/puma/single.rb:28:in stop_blocked' /usr/local/bundle/gems/puma-3.11.0/lib/puma/launcher.rb:291:in graceful_stop'
  /usr/local/bundle/gems/puma-3.11.0/lib/puma/launcher.rb:395:in block in setup_signals' /app/gtk_api.rb:112:in kill'
  /app/gtk_api.rb:112:in block in <class:GtkApi>' /app/gtk_api.rb:98:in each'
  /app/gtk_api.rb:98:in <class:GtkApi>' /app/gtk_api.rb:53:in <top (required)>'
  config.ru:28:in require' config.ru:28:in block in '
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:55:in instance_eval' /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:55:in initialize'
  config.ru:in new' config.ru:in '
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:49:in eval' /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:49:in new_from_string'
  /usr/local/bundle/gems/rack-2.0.7/lib/rack/builder.rb:40:in parse_file' /usr/local/bundle/gems/puma-3.11.0/lib/puma/configuration.rb:318:in load_rackup'
  /usr/local/bundle/gems/puma-3.11.0/lib/puma/configuration.rb:243:in app' /usr/local/bundle/gems/puma-3.11.0/lib/puma/runner.rb:138:in load_and_bind'
  /usr/local/bundle/gems/puma-3.11.0/lib/puma/single.rb:87:in run' /usr/local/bundle/gems/puma-3.11.0/lib/puma/launcher.rb:183:in run'
  /usr/local/bundle/gems/puma-3.11.0/lib/puma/cli.rb:77:in run' /usr/local/bundle/gems/puma-3.11.0/bin/puma:10:in <top (required)>'
  /usr/local/bundle/bin/puma:29:in load' /usr/local/bundle/bin/puma:29:in <top (required)>'

Since we can rely on RESTful to communicate with Openstack, and Java/Python inter-working is complex, bug-prone and inefficient, we should base the communication between the OpenStack wrapper and OpenStack end-point on HTTP RESTful communication.

IA must allow registerding a SPVim Wrapper to interact with the underlying Service Platform, through its GK.

as initial step for year 1 demo we would like to implement a simple deploy service flow.
more details from the MANO framework side can be found here -
sonata-nfv/son-mano-framework#23.

we need to define the Infrabstract-SLM Plugin APIs as 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

Glance client will be available soon to push images to OpenStack VIM(s).
Will the IA be responsible for the download?
Will the VNF image will be pre-downloaded by the SP and offered to the IA, or will the IA download the image from the link provided by the developer in the VNFD?
Should we provide a new API call to push the image in the VIM (a new FLM-IA interaction) or should the IA be responsible of taking track of what images are stored where and automatically download and push the image where it is needed?
How Container-based VIM affects this step?

Currently the IA offers an API call to add and configure WIM and VIM to the SP, but this is not in sync with the GUI and the GK API .
Payload with parameters for the API call should be updated and synced between the different micro-services.
In general we should decide if this feature is actually needed, or if the configuration of the IA in terms of VIMs and WIMs should be left to config files in the son-install scripts.

Allow service termination.

1. remove network setup
2. terminate containers

Hi,
I tried to use your WIM-adaptor. When I ran docker command to build adaptor I receive such trace. Please give me some advice what I should do with that problem or some workaround to run. (I also tried to build this project manually and checked if maven is ok and it is.)
Thank you,
Lukas

Step 25/26 : RUN mvn -q -e compile assembly:single;
---> Running in 375b948b514f
[ERROR] No plugin found for prefix 'assembly' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/root/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1]
org.apache.maven.plugin.prefix.NoPluginFoundForPrefixException: No plugin found for prefix 'assembly' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/root/.m2/repository), central (https://repo.maven.apache.org/maven2)]
at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:93)
at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:265)
at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:219)
at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:103)
at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:83)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:89)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException
The command '/bin/sh -c mvn -q -e compile assembly:single;' returned a non-zero code: 1

Apache Maven 3.3.9
Java version: 1.8.0_171, vendor: Oracle Corporation

Start simple Docker-based service using the new wrapper and the emulator's REST interface

vim-emu api should be separated from the wrapper

Forwarding path setup inside the emulator using the corresponding network/ endpoints of the REST API.

Due to a crash in son-broker (lack of memory), the son-sp-infrabstract, lost its connection with the bus. Even after restarting the son-broker, the connection is not established.

Error Logs:
[ERROR] connection is already closed due to connection error; cause: java.net.SocketException: Connection reset
com.rabbitmq.client.AlreadyClosedException: connection is already closed due to connection error; cause: java.net.SocketException: Connection reset
at com.rabbitmq.client.impl.AMQConnection.ensureIsOpen(AMQConnection.java:171)
at com.rabbitmq.client.impl.AMQConnection.createChannel(AMQConnection.java:500)
at sonata.kernel.vimadaptor.messaging.RabbitMqProducer.sendMessage(RabbitMqProducer.java:100)
at sonata.kernel.vimadaptor.messaging.AbstractMsgBusProducer.run(AbstractMsgBusProducer.java:93)
at java.lang.Thread.run(Thread.java:745)

Expectation
Connection to get re established when the crashed broker is up.

At building url time, only the authenticate() method contains the append port option. It's missing in getVims, getServices, ...

We want the IA to be as agnostic as possible about the "service" concept, letting SLM/FLM handle the service composition process during instantiation.

I think we can achieve this by incrementally "updating" the Heat template of the NS (using Heat update-stack function), as soon as VNFDs are pushed by the FLM to the IA. This can be done using a refined/simpler model for translating NSD/VFNDs into Heat stack. This includes single data-plane and control-plane networks created by the IA when the SLM asks for a new Service Instance, instead of Neutron Net and Router to represent VNF and NS virtual links respectively.

The foreseen steps as discussed on 2018-05-09:

• install full SONATA SP in VM (user version 3.1)
• replace standard IA with our patched IA that includes VEW code
• install emulator on VM
• deploy a first test service end-to-end
  • create a service package
  • on-board service package
  • instantiate the test service
  • check test service deployed in emulator (ping, http, etc.)
• build a shiny demo service for demonstrations

This is entangled with the northbound API definitions, so let's start the discussion also on this.
I prepare a set of interfaces and abtract class ready to extend and to implement to code the wrapper. Basing also on the API definition in the issue #2 we can isolate the kind of call to the VIM that needs to be implemented in the wrapper.
In this I would like to ask for help, expecially from people experienced with OpenStack and Heat, because we would need to implement a basic translator from the SONATA SD (or a subset of it) and the Heat template.
By now even the abstract classes and the interfaces for wrapper are empty so let's populate them basing on the MANO API definition, and then move to the specific wrapper implementation.

We need the Type of VIM in the answer of VIM list

1...n VNFs
1...m VDUs
....