#solum

--name solum_app /opt/jenkins_solum_poc/exported_image/python_app_deploy.tar

the cli uses rest calls in the background

we can probably wrap it in a shell script

indeed

but since we are running all the stuff in one VM

so I think it is alright for us to use the glance cli directly

we are able to make it work

what do you mean?

but what about the case if openstack is on another host

oh ok

in that case also using the cli would work

yeah correct

sorry

because we are setting all those variables

env variables

yep

yeah correct

ok, so we agree on using the cli

one more point related to cli is that

okay

but do we wrap all this in a shell script?

we are anyway going to use the solum cli also

okay that makes life easier

about wrapping it into a shell script — what value would it provide?

what if this changes everytime

--name solum_app /opt/jenkins_solum_poc/exported_image/python_app_deploy.tar

I agree about your assessment that we will have to parameterize

yeah

yes

would we pass the parameters to the script from the XML config?

something like: du-upload-script.sh <app-name> <tar-location>

we can probably or else parameters from one job can be passed to the next one

as well

where <app-name> and <tar-location> are passed in as job parameters?

right

yeah that could be one thing

or else parameters from previous job can be passed to the next one

so we will have to parameterize it I guess

see, if the parameters are going to be passed into this job, then we could probably use the parameters directly in the current code that you have

yes, we definitely need to parameterize this job

what I am not so clear is if we need to define a wrapper script

I feel that what you have currently is fine

okay

all we have to do is change the glance image-create command

glance image-create --visibility=public --container-format=docker --disk-format=raw --name <app-name> <tar-location>

here app-name and tar-location can be passed from previous job is what you meant?

and use the parameters that are sent in corresponding to app-name and tar-location

yeah

make sense

I think that should be fine

I think so too

Alright I will try that out and let you know how it goes

Post this the next challenge would be to get the du_id from glance

I think we will have to probably use app-name for that

and than pass the du-id to our next job which will be solum_deploy

yep

those would be the next steps

that will be job 4 in the new setup

as we just said we will combine current job 3 and job 4

correct

and than job 5 will be app deploy via solum

so I guess we will have 5 jobs

job 4 you mean, right?

job 4 will deploy via solum

job 4 will be get du_id

oh

actually getting the du_id can be done in the current job itselt

5 will be solum create_and_deploy

itself

okay

you mean club 3,4 and 5 into one

getting the du_id is going to be another one-liner glance command

yeah

no, I meant we combine current job 3 and 4 and add the line to get the du_id at the end of this new job

so that will be our new job 3

okay

then, the new job 4 will call solum

okay that should be fine

cool

so we will have 4 jobs

create docker images

yep

run test

upload image

deploy

+1

may be one more to upload the logs

:)

yeah

:)

so in all max 5

yeah.. max 5 jobs

yeah

and about setting all these parameters

like OS_USER_NAME, docker registry url etc etc

we can use our glue code

makes sense

this will give use a configurable pipeline

cool

yep

lets summarize what all things need to be done

yep

1) glue code

2) figuring out what parameters are needed in each job

3) figuring out how to pass parameters from one job to another

4) figuring out how to redirect console logs to a file

5) figuring out if we can POST the logs back to the app repository in gitlabs

yep

6) in solum, create and deploy app

shall we add this to our etherpad

yeah missed that one

yes, lets add this to etherpad

so this will be a new feature in solum?

will add these

actually we may not need a new feature

btw how do we store all the parameters

in a flat file?

we can use the current 'app create' and 'app deploy'

just that in the 'app create' we need to create a dummy app

but than we need a language pack also

which is what we were thinking that the 'app create_and_deploy' will do behind the scene

otherwise app create fails

good point

ok, in that case we have to figure out how to register an app without a lp

I think you had raised a bug for this before

yeah

cool, lets add all this to the etherpad

added

but not the app create part

btw this is one way to integrate solum and jenkins

where jenkins is being the driver

right

we will have to see how solum could drive this complete stuff

the other option is where solum is the driver

yeah

I am thinking we should not worry about that at this stage

yeah

so what do we do about solum app create and deploy

as a theoretical possibility that is an option

yeah

I guess we will have to add that option

okay

I will take a look at what is involved in that

alright cool

yep

let me quickly look at the etherpad

ashishjain: also, if you can add the paste links to the etherpad that will be helpful

all the links that you shared aboev