Design of a new function fedcloud server create

[tdviet]

Creating a new VM via fedcloud openstack server create is quite cumbersome. Users must:

1. Choose a flavor. And flavor names are different from sites to sites, users must check the flavor list and choose the proper flavor.
2. Choose an image. Although images are published via AppDB, not all sites follow the rules strictly.
3. Choose a network. Again, the network names are different from sites to sites.

These are the minimal options required for creating a VM. There are much more options like security groups, key names, ..., but most of them can be omitted if using the default values.

Overall, it is almost impossible to create a command fedcloud openstack server create --site <SITE> --vo <VO> that works on all sites, as the flavor names, image names, and network names are site-specific.

Therefore, I would like to design a new function fedcloud server create that will replace the fedcloud openstack server create. The initial design of the function is:

fedcloud server create --vo <VO> --site <SITE> --name <name>
                                 --flavor-specs <flavor-specs> --image-specs <image-specs> 
                                 --network-specs <default/public/private/new> --public-ip <true/false>
                                 <additional-openstack-options>

The options:

• flavor-specs: where users specify their requirements. The syntax could be a JSON object like the output of fedcloud openstack flavor list --long --json-output, e.g. {VCPUs: 2, RAM: 4098}, or maybe a more flexible string VCPUs==2, RAM>=4098, where operators like >=, =~ can be used. The syntax of jq could be considered, too, e.g. (.VCPUs == 2) and (.RAM >= 4098), it is well-known and flexible enough.
• image-specs: where users specify their requirements. The syntax is the same as flavor-specs, e.g. Name =~"*Ubuntu*20.04*" for selecting a Ubuntu 20.04 image. If users want to use images from AppDB, they can specify e.g. APPLIANCE_TITLE=="Image for EGI Ubuntu 18.04 [Ubuntu/18.04/VirtualBox]", or shorter APPLIANCE_TITLE=~"*20.04*"
• network-specs: network specification, if using default network, or explicitly choose public/private, or create new one
• public-ip: in the case of true and private networks are used, allocate floating public IPs for VMs
• all other options will be passed directly to the openstack server create command, e.g. key names, security groups, server counts.

The functions:

• interactive mode: asking users for any missing options/parameters or if multiple choices available for the specifications (e.g. multiple available flavors with 2 CPUs)

$ fedcloud server create

Choose a VO for your server:
1. vo.access.egi.eu
2. my.another.vo

Your choice: 1
...
Choose a flavor for your server:

• batch mode: do not ask anything, make decision for users. If multiple choices available, choose the best one according to some internal criteria, e.g. if multiple Ubuntu 20.04 available, choose the newest one. Raise errors if required parameters are missing (site, vo), or no available choices for the specifications.

By that way, users will be able to write a command for creating VMs that will work on all sites:

fedcloud server create --vo vo.access.egi.eu --site IISAS-FedCloud --name testing 
                       --flavor-specs "VCPUs==2" --image-specs "Name=~20.04"
                       --network default --public-ip true

Your comments and suggestions are highly appreciated. Especially for the syntax of flavor/image specifications, once we have decided, it is difficult to change.

[sebastian-luna-valero]

I think this is a great addition to fedcloudclient. I have no additional suggestions at this point.

[gwarf]

Looks like it could be a nice addition!
I'm not really fond of using a JSON-like syntax JSON or even more like jq, it may be confusing (or remembering people bad experiences with jq when trying to do advanced things with it... ;) ) and not sure what would be the exact benefit. I'm not sure there is a need to have a very complex/flexible flavour definition, CPU and RAM specification being probably the most relevant points.
From your list something using the VCPUs==2, RAM>=4098 seems nice and intuitive enough, I guess it could be easy for people to understand/deal with this.
Another option could be to have separated options like --vcpus 2 and--ram 4096 (assuming the parameters would act by default as >=), maybe it could be easier/more clear for users than a composed parameter?
Not the most important, but the parameter for the RAM could allow to specify a suffix like 512M or 2G.

[martaguti]

Hi @tdviet

Having a look through the network settings, it is not homogenous. (not all sites do public/private)
e.g. fedcloud openstack network list --long --site ALL_SITES --vo vo.access.egi.eu

1. If you decide to create a new one --network new would you maintain the types of network that each site creates?

2. Is default network something you can query from openstack? (Had a look network list options but didn't see a way)

[tdviet]

1. some prefixes for networks created by fedcloudclient for maintaining (deleting it together with VMs, cleaning)
2. some ongoing activities in fedcloud for defining default network.

[giannidallatorre]

The command is certainly an excellent idea, to make it useful in most real use cases, the interactive selection should be likely expanded to the user key and the security group options.
I would also suggest that the command create only the VM and consume other available resources already created (i.e. just use an available floating IP, but not allocate a new floating IP from a pool, or the same for user-key), to make maintainable the environment, possibly associating to the create command its brother destroy, and avoiding having to deal with derived resources, which would require a state.
The idea is that these other resources should be explicitly generated, otherwise we move to a field that is covered by more complex CLI/applications like Terraform.

[tdviet]

The main reasons for using JSON compatible syntax (JSON, jq, ...) for specification:

• Too lazy to invent a new syntax :-)
• Existing libraries for processing the input parameters
• Extensible. For example, users may need flavors with 2 GPUs. With JSON-compatible syntax, such specs will be automatically supported.

The main reasons against the JSON-like syntax, as you have mentioned, the existing syntaxes of JSON, jq, JMESPath are too complex, even for IT experts. Simple CLI syntax e.g. --vcpus 2 --ram 4096 --gpu 2 are more user-friendly. However, they are not extensible, each parameter need to be addressed separately.

Some recommendations of simplex, user-friendly syntaxes, like the mentioned VCPUs==2, RAM>=4098, with Python libraries for processing them, are highly appreciated.

[tdviet]

Thank you all contribution. Your comments are highly appreciated, even if I cannot answer all (need some time for thinking before answer). Note that the idea is still in early design, anything can be changed, and you can decide how the final product will look like

[thebe14]

The only problem (besides the complexities of the OpenStack server create command) I see is with what proposed so far is that if this command allows something like cpu >= 2 this may have the undesired effect of huge VM flavors matching, with hundreds of cpus. These requirements must be exact.

[tdviet]

Users can choose best match (or recommendation mode), for example if >= is used, so by default recommend the the flavor with closed value to the right side. Of course, == is better but >= may be useful, too.

[thebe14]

associating to the create command its brother destroy, and avoiding having to deal with derived resources, which would require a state.

All resources have a state already. E.g. you cannot delete a sec group until it is being used.

The idea is that these other resources should be explicitly generated, otherwise we move to a field that is covered by more complex CLI/applications like Terraform

Exactly. In my opinion you will never (or rarely) create a VM for which you will not connect some other, sometimes persistent, resources/services. VMs with just default values and automatically generated network, sec groups, etc. are not very useful. Which makes deletion of a VM a very thorny problem.

[giannidallatorre]

associating to the create command its brother destroy, and avoiding having to deal with derived resources, which would require a state.

All resources have a state already. E.g. you cannot delete a sec group until it is being used.

Yes, they have a state managed by OpenStack.
Still a deployment state could be necessary if you create, with a single command, several logically connected resources and you want to clean up everything with just a single command.

I am probably not clear enough, will try with an example:
the creation of a VM providing a new ssh-key interactively, this would trigger a new OpenStack resource.
Once you deleting the VM, there will be at least one logically-connected resource to the VM (the OpenStack key) that you can:
a) remove while destroying the VM (which will require keeping a state describing the deployment)
b) ignore it, with several eventual drawbacks: quota consumption, use of a different tool for the deletion, deployment failure due to a name clash if successive deployments use the same name for generating that resource.
The most problematic point of b) is that the end users usually is not that aware that he has created, if you offer him something interactive, so he will likely not cleaning up the shared environment.

[tdviet]

Thank you all for very useful discussion. Based on the discussion, I have revised the design and this is the summary:

• fedcloud commands should be used like a shell, for interactive work or for simple scripting. The commands should be simple, should do only one thing, and mainly should not go to the area of full automation of Infrastructure Manager or Terraform.
• --network new is certainly a bad idea, it is against the design mentioned above. If users want to create a new network, they can explicitly create it then add option --network new-network-id. Sorry for the confusion and bad design.
• even in the case of using Infrastructure Manager, Terraform or other automation tool, fedcloudclient can be helpful. See EC3 CLI documentation to see how fedcloudclient is used in combination with IM/EC3.
• Again, in the example of EC3 CLI, users still need to choose flavor and image names manually. Some command like fedcloud select flavor --site <SITE> --vo <VO> --flavor specs <flavor-specs> for getting suitable flavors could be useful. Similar we can create fedcloud select network, fedcloud select image and so on.
• If we have fedcloud select * commands implemented, fedcloud server create command can be easily created as the combination of the mentioned commands.
• So the focus of the design now could be shifted to the fedcloud select * commands. Just simple commands, do one thing and do it well. The fedcloud server create, in interactive mode can still work as it is designed. In the batch mode it is just the combination of fedcloud select * commands and fedcloud openstack server create.

What do you think about that?

[tdviet]

The first version of the fedcloud select flavor is created and merged to the main branch. I tried to address all concerns mentioned in this discussion:

• The specs are still based on JSON, but with very simple syntax. The specifications may be repeated multiple time e.g. --flavor-specs "VCPUS==2" --flavor-specs "RAM>=2048", or may be merged together with & operator --flavor-specs "VCPUs == 2 & RAM >=2048". Both ways are simple and easy enough for end-users.
• Shor-option alternatives are available, e.g. --vcpus 2 is equivalent to --flavor-specs "VCPUs==2".
• The output is sorted, best-matched (least resources) first, so users can safely choose the first one.
• Several output options --flavor-output [first | list | YAML | JSON]. The first one is suitable for scripting and automation.
• Most of errors/exceptions should be caught with sensible error message, however, please do more testing

Usage: fedcloud select flavor --site IISAS-FedCloud --vo vo.access.egi.eu --flavor-specs "RAM>=2096" --flavor-specs "Disk > 10" --vcpus 2 .

Execute fedcloud select flavor --help for more information. fedcloud select image, fedcloud select network and similar ones will come later.

[tdviet]

fedcloud select image and fedcloud select network commands have been added.

[sebastian-luna-valero]

Hi,

I have been playing a bit with the new commands and below are my comments.

Comment 1

--site and --vo options are mandatory for fedcloud select commands. I think it would be great to have it working for --vo only (for those VOs that span across multiple sites, e.g. vo.access.egi.eu, training.egi.eu)

Comment 2

fedcloud select flavor has the option --flavor-output
fedcloud select image has the option --image-output
fedcloud select network has the option --network-output

Would it be better to have the option --output-format for them all?

A similar suggestion for --flavor-specs, --image-specs, and --network-specs. They could all be --specs.

Comment 3

fedcloud select network --help says that --network-specs is required, however fedcloud select network --site IISAS-FedCloud --vo vo.access.egi.eu --network-output list works without it.

Many thanks!
Sebastian

[tdviet]

@sebastian-luna-valero Thanks very much for testing, also for fixing the cheat sheet :-)

For your comments:

Comment 1: I will add support for --all-sites option. Initially I thought that the flavors and networks are very site-specific, but by reading your comments, I realized that the --all-sites option may be useful, especially if users are looking for some special flavors (e.g. very large RAM, GPUs) that are not commonly available on all sites.

Comment 2: There are two main reasons for different -*-specs for each command: The first one is rather simple: each option has a different help text. e.g. for flavor:

    --flavor-specs flavor-specs   Flavor specifications, e.g. 'VCPUs==2' or
                                  'Disk>100'. May be specified more times, or
                                  joined, e.g. 'VCPUs==2 & RAM>2048'

The second reason is the preparation for the future fedcloud server create command, so users can use the same option name fedcloud server create --flavor-specs --image-specs --network-specs.

For output option --output-format, I was thinking about possibly different ways of printing output for different commands, but still not have clear design. If we agree on current formats of outputs, we can have a common option for output format.

Comment 3: As there is the default value, the option is indeed no longer required. Fixed. Thanks for suggestions.