#solum

have been busy with other stuff

I think we should concentrate on one stuff at one time

do you want to chat now (have half an hour) or we could do it tomorrow for more time

yes

half an hour today is fine

never know what happens tomorrow

okay. :)

give me few mins.

let me dig up the email

ok

you mentioned using the build-api service to build an image corresponding to custom lang pack and upload it to glance.. makes sense to me.

in the irc meeting another point of view came up as well.

What will be the input to build-api and what will be the output

what is that?

let me explain the other pov. a custom lang pack is nothing but a image with a predefined entry point (a wellknown script at a wellknown location on that image).

we did not go much further on that line of thought. we could explore that right now.

so lets say app developer wants a custom lang pack with chef related testing tools (chef spec, test kitchen, etc.)..

And that script takes care of setting up the environment

yes.

but continuing with above example, an app developer would still need to provide that script

So now the onus is on the developer to provide the image with this script.

or have a hook that calls some other script to setup the environment

that is one view. operator could also make available some base image

and app developer customizes it (by providing the script)

base image which pulls a script from common location?

and common location being swift?

metadata?

explain more..

oh okay.. so you are saying we could store the script in the metadata service

yes

or the location of the script

yeah, in the case the script itself could be some place else.

So, solum assumes that developer has the correct image

okay.. so going back to the use-case of chef.. as an app developer I write the script to install the required packages and upload it to metadata service. Then I call lang pack api (something like, POST /language-packs with {base_image_id, script location} as data

which will bootstrap to setup required environment

I was thinking that solum will provide certain base images

it will be developers responsibility to provide and use the right script

developer might have a single script to work with different OS flavors

we could use the build-api resource actually

for what?

instead of the language-packs resource

i mean for the POST kind of call.. its a minor point though

main idea is developer asks solum to create a custom language pack (image) by specifying two things:

- base image id (already available in Solum)

- location of a script

If we are going to go with this approach, I don't think we should care about this at all

care about what?

base image and location of the script

why do you think we need that?

how so? wouldn't Solum need to know what base image to start with and what script to inject in the wellknown location on the image and then invoke it?

instead developer can give the image

yes, for that use case, solum is would not be really helping create custom lang packs at all.. solum will be basically supporting use of custom lang packs

yes

may be that is okay.

in that case,

solum just needs to prescribe the wellknown location

right?

the case where developer has no intention to provide the image and rather use some image that solum certifies?

along with a script?

what about that use case? it would still not require anything different from solum as compared to when users register their image, right?

I think we are discussing two cases here

1. In which developer already has an image. He uploads the image to glance. Gets the image id. Creates the language pack with this id.

yes, that is one use case

2. We provide a base image and developer provides a script to customize the image to get a new one and upload it.

totally agree.. and I thought you were suggesting that use case 2 we should not consider..

My concern is, if we provide the base image, do we need to support that image.

There will be issues raised against that image

by the user

if an operator supports any image, then yes, they would have to keep up with patches etc. on those images

but that would be a standard operator procedure, right?

you said solum providing base image.

For the first case, do we have anything specific to work on?

what I meant was, for use case 2, yes - solum operator can provide base image

for use case 1

ah

so you emant solum operator. I thought solum project will host.

sorry. yeah, I meant solum operator

so for use case 1, the main thing that jumps out is ability to 'tag' images with keywords so that a developer can do glance-list (or GET /langaugage-packs/) and get back results that identifies what each custom lang pack contains

I think the idea of language pack is to provide metadata about the image.

it is.. so I don't think we need anything additional except for tags to support first use case

I am yet to understand why do we need tags?

as an app developer, I may have several custom lang packs (one for chef, one for c#, etc.).

guys, I'd rather not be in the business of developing and supporting language packs

so some way to know what each contains (glance image ids would not be useful here)

as an open source project

there are build packs already out there that others are supporting, and that work fine

let's provide mechanisms to pull in and use those

and allow solum operators to provide their own

which specifically you have in mind?

the Heroku ones and the CF ones would be a great start

heroku, openshift, cf, each are bit different

and we may want to add openshift cartridges as well

adrian_otto: Solum doesn't care about which does not fit into these packs

but we should not put ourselves in a position where we are being prescriptive about how a particular language should be build, tested or run.

let the experts in each language determine that organically

noorul: I do not understand your remark

adrian_otto: I do not think everyone is using heroku or whatever you mentioned above.

okay. thats a fair point. noorul, need to leave, will sync back again to find out what comes out of your and adrian_otto's discussion

as long as there is a way for a cloud operator (and optionally an end user of Solum) to register his/her own LP, then what compatibility features we have for popular runtimes is a non-issue.

we just offer an example environment, and instructions for how to set up your own

I was trying to solve a use case in my company

and that's really not going to be that hard. It's creating a container image with a script in it. The script name is either fixed, or specified in the plan file. Sone.

s/Sone/Done/

noorul: ok, tell me more about that use case please

adrian_otto: Was this discussed earlier? Having a script in plan file?

the script can be within the container image specified by the LP, and the name of it can be in the plan file (if the default script name is not sued for some reason)

s/sued/used/

for example, maybe we execute /opt/build.sh and /opt/test.sh by default, and if you want something different, then you can specify it…. perhaps as part of the pipeline.

makes sense

ok, so looking at https://etherpad.openstack.org/p/custom-languag... lines 6-12

you have a custom language pack, and a custom pipeline in that case

at the end of the testing pipeline, you produce a container image that has the start/stop script in the init scripts

Yes, that is what we were discussing.

then when that image is deployed, the start script gets called, and your app starts

so that use case should be fully supported, provided the developer makes the LP and registers it.

The question are we there?

Or do we have some coding left to be there?

we do not have pipelines that can be changed by users yet

so you would be limited to what the default workflow does today

Also we only deal with docker

there is a working VM build as well

Hmm james-li was struggling to write functional tests without docker

yes, because we wanted our default CI to use Docker so we did not add 20+ minutes of time to every gate check

we could have tests that do VM creation in the build instead of a Docker build

they just run slower