In general the lab does not necessarily have to be open to the "general public" and can have the same access control as physical labs. Therefore the VNF licenses used in physical labs should be applicable to the virtual lab as well. I updated the document and added slide #7 to address this explicitly
I wonder if we can describe this more as requirements from a developer perspective.
Let me outline what I mean:
Compute/Lab support for ONAP ——————————————
Lab type 1:
An environment developers use to actually write the code and perform unit testing. I would generally assume that those labs are installed and maintained by the organization the developers works for. To make this work we have to provide a “standard” configuration for these environments. If we don’t we will get an endless number of emails like “foobar does not built on my ….” as we are already seeing on the mailing list now. Dependencies of ONAP are complex and it won’t just build everywhere… .
Lab type 2:
On a daily basis each developer should be able to test his component in an integrated setting. Let’s assume we have 11 or so components in ONAP. That means the developer of component X needs to be able to spin up ONAP with the 10 other components configured in a way which allows for some “simple” integration use cases to execute. I know some people see this kind of lab as a luxury. I see it as a must if you are serious about CI/CD. Now what do we need to make this happen:
- we need a space to spin this up - we need a standard integration configuration of all 11 components. - we need to do this very flexibly (e.g. a developer shouldn’t have to wait for a particular time zone to wake up or get a slot in a lab”
This all calls for a virtual lab. A virtual lab would allow a developer to spin up a new ONAP instance in isolation without impacting anybody else. Run the simple integration tests, debug them and shut them down again.
We would have to provide to the developers the standard configuration and an easy way to spin one up (at the push of a button). In terms of providing the actual environment there are multiple options. LF pays. Developer org pays. Partner donates. I don’t really care which one it is as long as it doesn’t restrict the developer as the developer is by far the most expensive resource here.
Lab type 3:
Performs complex integration tests with PNFs and E2E service use cases.
Those labs do require hardware for the PNFs. Now the interesting part here is that we can separate the PNF/VNFs from the actual ONAP instance. As discussed yesterday ONAP itself can really run anywhere. The cloud and physical environment constrains come in on the PNFs / VNFs. So we could e.g. run ONAP in the virtual environment above (to minimize the number of configuration we support) and have them control PNFs and VNFs in a remote lab. There is really no requirement for co-location and in fact we are running the ECOMP control plane entirely separate from the VNFs/PNFs in our network today for security and resiliency reasons alone. So this mode of operations is actually preferred in practice.
This also means that we could use any lab we want for the PNF/VNF setup and control them from any virtual ONAP instance. All we would have to do is to agree on a standard tunneling technique to ensure connectivity between ONAP and the cloud layer/VNF/PNFs in that lab.
Lab type X:
deals with none development related things like certification, demos etc.. . I am less worried about this right now as we have more time to work this out.
I would structure our labs in those categories and focus on providing the artifacts to make them happen ASAP.
This makes a lot of sense. It also makes the task of creating a standard "blueprint" and "package" highly important. A few clarifications:
Where is the official CI/CD of ONAP executed? I am assuming that is not necessarily done in any lab type described above but rather in a dedicated lab as described here: (obsolete)Open Lab
The "packages" for lab types 1&2 - Will those have to be frequently updated to include the "trunk" build of ONAP? Will they automatically pull the latest build? Will they use a "stable" build instead?
Local Maven/Jenkins/Nexus is required to reduce the traffic with the LF CI/CD foundation then each Lab1, 2, 3, X can benefit from this CD local infrastructure.
This makes sense we need to separate the environments that spin up , do tests and spin down for developers to get immediate feedback on their work/code/bug fixes and separate environments for things that require hard assets (PNFs) and/or long term testing (stability and scale for instance)
Per Lab Center ((obsolete)Open Lab and Physical Labs), we indeed need to understand what type of labs they can support and their scope.
We have identified at least 4 different labs as part of the Integration project (Integration (5/11/2017)):
1 Lab non-resilient for Development Team (immediate)
1 lab resilient for CIST Team (immediate)
1 lab resilient for E2E Team (immediate)
1 lab resilient for S3P Team (medium term - dependencies on Performance KPIs; Limited Performance testing will be performed as part of ONAP R1).
Can we also consider the following feedback as part of the deck? thank you
the importance of Configuration Management
the lab availability and notification i.e. any maintenance/outage or special lab booking for a demo event etc.
Usage Tracking Tool (slides 5/13) - is it to measure the ONAP consumption in order to fine-tune the resources and later to build a dimensioning tool?
Link the ONAP Operations Manager project with the slide 6-Ease of use?
ONAP should be OS agnostic (slide 8)
Limit OpenStack flavor for certification purpose (slide 8)
VMWare is also not free and will require licenses so we should not recommend it (slide 8)
Need to check if the lab centers are opened to be inter-connected together as defined on slide 9 (not sure based on the current proposal) Somehow it would be great if we could handle these interconnections to test resiliency/elasticity across regions (APAC, NAR, EMEA etc).
Slide 14, incomplete last sentence - I believe you meant 'Approving the Virtual Lab proposal
At first I thought by "OS Agnostic" you meant "Open Stack agnostic", which I kind of understand. But Could you please clarify what does "Operating System Agnostic" mean? Currently, as far as I understand, ONAP (ECOMP) is packaged in VMs, so it brings its own Operating System. Do you see a shift to packaging of ONAP software only, to be run on any Linux (either virtual machince or physical)?
Slide 13: Is there a reason ARM is explicitly excluded? Can you elaborate more on the following statement? What certification authority are you referring to? Is there a minority of VNFs certified on other platforms?
The majority of VNFs are only certified to run on X86
Right. While it is true that a majority of VNFs today are only supported on x86, ONAP is and must remain multi-architecture, and there are VNFs, including open source, that are ported to ARM/supported on ARM that can be tested. Further, there are numerous avenues for virtual labs. Let's not be exclusionary here, folks...when there is no reason to be.
13 Comments
Lingli Deng
Thanks for the proposal. Is there any licensing requirements for remote participation of VNF vendors or third-party devices/physical labs?
Ranny Haiby
In general the lab does not necessarily have to be open to the "general public" and can have the same access control as physical labs. Therefore the VNF licenses used in physical labs should be applicable to the virtual lab as well. I updated the document and added slide #7 to address this explicitly
Lingli Deng
Thank you.
Oliver Spatscheck
I wonder if we can describe this more as requirements from a developer perspective.
Let me outline what I mean:
Compute/Lab support for ONAP
——————————————
Lab type 1:
An environment developers use to actually write the code and perform unit testing. I would generally assume that those labs are installed and maintained by the organization the developers works for. To make this work we have to provide a “standard” configuration for these environments. If we don’t we will get an endless number of emails like “foobar does not built on my ….” as we are already seeing on the mailing list now. Dependencies of ONAP are complex and it won’t just build everywhere… .
Lab type 2:
On a daily basis each developer should be able to test his component in an integrated setting. Let’s assume we have 11 or so components in ONAP. That means the developer of component X needs to be able to spin up ONAP with the 10 other components configured in a way which allows for some “simple” integration use cases to execute. I know some people see this kind of lab as a luxury. I see it as a must if you are serious about CI/CD. Now what do we need to make this happen:
- we need a space to spin this up
- we need a standard integration configuration of all 11 components.
- we need to do this very flexibly (e.g. a developer shouldn’t have to wait for a particular time zone to wake up or get a slot in a lab”
This all calls for a virtual lab. A virtual lab would allow a developer to spin up a new ONAP instance in isolation without impacting anybody else. Run the simple integration tests, debug them and shut them down again.
We would have to provide to the developers the standard configuration and an easy way to spin one up (at the push of a button). In terms of providing the actual environment there are multiple options. LF pays. Developer org pays. Partner donates. I don’t really care which one it is as long as it doesn’t restrict the developer as the developer is by far the most expensive resource here.
Lab type 3:
Performs complex integration tests with PNFs and E2E service use cases.
Those labs do require hardware for the PNFs. Now the interesting part here is that we can separate the PNF/VNFs from the actual ONAP instance. As discussed yesterday ONAP itself can really run anywhere. The cloud and physical environment constrains come in on the PNFs / VNFs. So we could e.g. run ONAP in the virtual environment above (to minimize the number of configuration we support) and have them control PNFs and VNFs in a remote lab. There is really no requirement for co-location and in fact we are running the ECOMP control plane entirely separate from the VNFs/PNFs in our network today for security and resiliency reasons alone. So this mode of operations is actually preferred in practice.
This also means that we could use any lab we want for the PNF/VNF setup and control them from any virtual ONAP instance. All we would have to do is to agree on a standard tunneling technique to ensure connectivity between ONAP and the cloud layer/VNF/PNFs in that lab.
Lab type X:
deals with none development related things like certification, demos etc.. . I am less worried about this right now as we have more time to work this out.
I would structure our labs in those categories and focus on providing the artifacts to make them happen ASAP.
Ranny Haiby
This makes a lot of sense. It also makes the task of creating a standard "blueprint" and "package" highly important. A few clarifications:
Catherine Lefevre
Local Maven/Jenkins/Nexus is required to reduce the traffic with the LF CI/CD foundation then each Lab1, 2, 3, X can benefit from this CD local infrastructure.
Brian Freeman
This makes sense we need to separate the environments that spin up , do tests and spin down for developers to get immediate feedback on their work/code/bug fixes and separate environments for things that require hard assets (PNFs) and/or long term testing (stability and scale for instance)
Catherine Lefevre
Per Lab Center ((obsolete)Open Lab and Physical Labs), we indeed need to understand what type of labs they can support and their scope.
We have identified at least 4 different labs as part of the Integration project (Integration (5/11/2017)):
Can we also consider the following feedback as part of the deck? thank you
Somehow it would be great if we could handle these interconnections to test resiliency/elasticity across regions (APAC, NAR, EMEA etc).
Ranny Haiby
Updated the slides based on the comments
Catherine Lefevre
Sounds great - only one comment: ONAP should be Operating System agnostic (slide 8)
Ranny Haiby
At first I thought by "OS Agnostic" you meant "Open Stack agnostic", which I kind of understand. But Could you please clarify what does "Operating System Agnostic" mean? Currently, as far as I understand, ONAP (ECOMP) is packaged in VMs, so it brings its own Operating System. Do you see a shift to packaging of ONAP software only, to be run on any Linux (either virtual machince or physical)?
Brian Hedstrom
Slide 13: Is there a reason ARM is explicitly excluded? Can you elaborate more on the following statement? What certification authority are you referring to? Is there a minority of VNFs certified on other platforms?
Bob Monkman
Right. While it is true that a majority of VNFs today are only supported on x86, ONAP is and must remain multi-architecture, and there are VNFs, including open source, that are ported to ARM/supported on ARM that can be tested. Further, there are numerous avenues for virtual labs. Let's not be exclusionary here, folks...when there is no reason to be.