Release properties validations (before deployment)

[allomov]

Hey, all.

A lot of errors can occur because of a "human factor". I mean that errors in BOSH manifests can be caused by misspelling or misunderstanding of BOSH release properties. Even if BOSH can check some type of errors in manifest properties, often it is not enough.

I am pretty sure that teams that are implementing BOSH release are the best people who can put reasonable validations to properties fields. That's why I'm sure that it will be a good thing to provide a way to add validations to BOSH release properties during implementation. At this moment job spec (example) contains only following fields: description, default and the name of the property. I suggest adding type and validations fields to this sections. The easiest way to validate properties will be checking their types and validating across regexp.

This feature will allow to aware user to set database schema to postgresql, not postgres and will save user's time to find out what's wrong.

What do you think about this feature?

[cppforlife]

We are planning to add some kind of types for the properties. I have not had a chance to write something up yet.

Imho there are several common high level types and few basic types that we should introduce. For example basic types could be: string, int, float, array of X. For the high level types I think there are a few ones centered around networking: port, IPs, domain, etc. and some around credentials: SSL certs, passwords, usernames, uuids.

Different levels of validations could also be involved here: some basic checks against the types, and more complex dependency like validations. For example if some property is specified, user must specify another property, possibly with specific set of values. I'm not sure we can easily describe more complex case without making an extremely verbose definition. At that point it's probably not worth it, but for the simple cases when we could check on the length, etc it's definitely something I'm looking forward to.

[allomov]

Hey, @cppforlife. I decided to move our discussion here.

I like an idea to run validations on bosh-director side, still there are lots of questions for me:

1. do you plan to implement a validators only for properties (such as checks for property types) or do you plan to validate in more complex way the whole deployment manifest (checking for using unnecessary properties, checking if jobs support selected stemcells)?
2. What about job specific validations (for example, when one job should not be colocated with another)?
3. How do you plan to extend validators? Will it be possible to provide custom validators?
4. Are you going to create a bosh director endpoint to return release properties? (I'm interested because it will allow to build meta services based on BOSH)

Thank you.

[cppforlife]

I've finally collected my notes and pushed 5301f6f. Hopefully that gives you an idea of what I'm currently planning.

And to answer your questions above:

1. do you plan to implement a validators only for properties (such as checks for property types) or do you plan to validate in more complex way the whole deployment manifest (checking for using unnecessary properties, checking if jobs support selected stemcells)?

• unnecessary properties validation is planned
• stemcell version checking is not quite there

1. What about job specific validations (for example, when one job should not be colocated with another)?

this one is an interesting one. can you give me few concrete examples you are thinking about?

1. How do you plan to extend validators? Will it be possible to provide custom validators?

i'm not eager to introduce custom validators just yet. may be that would be something that config server could be expanded to do. any concrete examples?

1. Are you going to create a bosh director endpoint to return release properties? (I'm interested because it will allow to build meta services based on BOSH)

i think it makes sense to expand API bosh inspect release uses to return more job metadata. PR welcome for this one.

[allomov]

Thank you for the answer. I will dig deeper into bosh inspect release later.

Talking about examples of job specific validations, here are some I can think of:

1. cluster of etcd jobs shouldn’t contain even number of instances.
2. login job shouldn't not be used if you use cf v214 and higher
3. check situation if job uses the same path on file system to store data with another job and this can cause a conflict
4. some time ago (in times of login=>uaa transition) Login and UAA templates could not work together on a same job.

It also would be nice to have possibility to print warning messages (enabled by some flag), if you are trying to run HA / production deployment. For instance, the verificator could print warning for the case if you don't have redundancy on some job or something. Using metadata from release you can even calculate expected downtime during upgrade and do other great stuff.