Basic blueprint for creating a VDC

[yveskerwyn]

In AYS the most basic blueprint for creating a VDC looks like this:

g8client__cl:
    instance: switzerland
    account: myacc

vdc__myvdc:
    g8client: cl
    location: ch-gen-1

actions:
    - action: install

This valid (tested) blueprint assumes that:

• there is already a $REPO-NAME_main config instance for OVC on the 0-robot host; note the $REPO-NAME in the name of the config instance
• there is a main config instance for ItsYou.online for an IYO user with write access to myacc

Question is how would this translate in 0-robot-land?

Not sure... here's a try (partly inspired by the current OVC 0-template code):

services:
    - github.com/openvcloud/0-templates/openvcloud/0.0.1__switzerland:

    - github.com/openvcloud/0-templates/account/0.0.1__myacc:

    - github.com/openvcloud/0-templates/vdc/0.0.1__myvdc:
           location: ch-g8-4

actions:
    - template: github.com/openvcloud/0-templates/vdc/0.0.1
           actions: ['install']

[zaibon]

services:
    - github.com/openvcloud/0-templates/openvcloud/0.0.1__switzerland:
        address: https://be-g8-1.demo.greenitlobe.com
        port: 443   
        login: mylogin
        token: jwtotken

    - github.com/openvcloud/0-templates/account/0.0.1__myacc:
        openvcloud: switzerland

    - github.com/openvcloud/0-templates/vdc/0.0.1__myvdc:
        account: myacc

I would say something like that. @muhamadazmy can you confirm that's what you had in mind ?

[muhamadazmy]

Yes, the bp from @zaibon is correct. basically it works like this

• You define a connection (address, and user credentials + token)
• You define an account (that links to an openvcloud connection
• You define a VDC (that links to an account)
• Then next, you define a VM that links to a VDC

We try to avoid linking vdc, and vm to the connection since it's implicitly known from it's parent

[yveskerwyn]

login and token are optional, right?

I was expecting that 0-robot would get that info from the main ItsYou.online jsconfig instance, no?

The same for address and port, 0-robot should be able to get this from the (in this case) switzerland OpenvCloud jsconfig instance, no?

And what happened with the location field in the vdc schema, we need that in order to create a cloud space, or not anymore?

[muhamadazmy]

The login and token are not optional currently, but if u wanna make them optional, then we will have to define a template for itsyouonline object, since we can't always use main

the address and port can not be optional because it's the openvcloud template that defines the switzerland ovc connection, hence the ovc connection should not exit until u run the bp.

currently the location is still required, i wasn't sure if the location is always same as the ovc connection name, i didn't know if the same ovc can have multiple connections, hence i left it as it is. If it's always the same we definitely can change the code to make it optional or remove it entirely

[yveskerwyn]

I think we need the input from @rkhamis too, since I'm afraid we're not leveraging all config management features as we do in AYS 9.3.0, the above is a step back to me...

[zaibon]

That's the opposite we leverage the full config manager. Now you only have one service that creates the client configuration. Then any service that need a connection just need to know the instances name.

[yveskerwyn]

ok, that was actually my question, how would a blueprint for creating a VDC look like in case the IYO and OVC instances already exist? In AYS 9.3.0:

g8client__cl:
    instance: switzerland
    account: myacc

vdc__myvdc:
    g8client: cl
    location: ch-gen-1

[yveskerwyn]

Also what is the equivalent of this: https://github.com/openvcloud/ays_templates/tree/master/docs/OVC_Client

[muhamadazmy]

https://github.com/openvcloud/0-templates/issues/21#issuecomment-367229318

I think OVC_Client is the g8client in ays, which is now called openvcloud

[yveskerwyn]

@zaibon, about your blueprint:

services:
    - github.com/openvcloud/0-templates/openvcloud/0.0.1__switzerland:
        address: https://be-g8-1.demo.greenitlobe.com
        port: 443   
        login: mylogin
        token: jwtotken

    - github.com/openvcloud/0-templates/account/0.0.1__myacc:
        openvcloud: switzerland

    - github.com/openvcloud/0-templates/vdc/0.0.1__myvdc:
        account: myacc
        location: ch-gen-

Will it create a new jsconfig instance for OVC with name switzerland.

If yes, is it then correct that the next blueprint will use that jsconfig instance for OVC:

services:   
    - github.com/openvcloud/0-templates/account/0.0.1__myacc:
        openvcloud: switzerland

    - github.com/openvcloud/0-templates/vdc/0.0.1__myvdc2:
        account: myacc
        location: ch-gen-1

[zaibon]

Yes you can then reference the already created config in your future account and vdc

[yveskerwyn]

Also note that the current schema of a jsconfig for OpenvCloud is like this:

data = {
    'address': '...',
    'port': 443,
    'appkey_': '...'
}

So the login included here above is not valid, since that's rather something that is based on the jsconfig for ItsYou.online, implicitly linked to app_id and secret; there simple is no login anymore.

[yveskerwyn]

What if you have multiple 0-robot instances running on a host?

They will share the same jsconfig instances?

Or even worse, they can override each other's jsconfig instances if they use the same name...

In AYS 9.3.0 this problem doesn't exist because the name of the jsconfig instance is always prefixed by the name of the AYS repository... so you end up with repo1_switzerland an repo2_switzerland

[zaibon]

What if you have multiple 0-robot instances running on a host?

Doesn't matter if they use a different config repo

but there is still an issue we need to solve: What if you have multiple 0-robot instances running on a host?

[yveskerwyn]

so after all, we will support to have more than one config repo per host?

(not yet supported in the development branch AFAIK)