#solum

asalkeld: morning

hi noorul

how are you doing?

good, had some good days off (easter)

oh I see

and you?

I am ok

Tons of commitments in office

ok

I thought of asking you, all of a sudden why are we giving importance to UI?

noorul, just to be able to demo at the summit

I am just giving it one more day

then will get a discussion going on design

Do we have a slot @ Summit for this?

noorul, kinda

we will have to grab some unconferences I guess

Oh I see

asalkeld: Where will you be staying @ Atlanta?

hang on, I'll look

I will be put up here http://www.westinpeachtreeplazaatlanta.com/

The Westin Peachtree Plaza

cool

peachy ;)

That's great :)

Have you bee to Atlanta before?

s/bee/been

yes, but not the center

really flat spread out suburbs

Oh I see

When are you reaching there?

the day before ~6pm

(sunday)

I am expected to reach there on same day at 9 pm

ok

Angus Salkeld proposed a change to stackforge/solum-dashboard: Add the ability to create an assembly from an application https://review.openstack.org/90635

erg: hopefully the end of my gui building days

he he

Angus Salkeld proposed a change to stackforge/solum-dashboard: Add some basic install instructions https://review.openstack.org/90637

A change was merged to stackforge/solum-dashboard: Add some basic install instructions https://review.openstack.org/90637

julienvey, you about?

asalkeld: yes

hi, I made some changes to https://wiki.openstack.org/wiki/Solum/ApiModel

let me know what you think (if you have a moment)

asalkeld: sure!

urg: formatting sucks

I think I prefer that dsl

I like this definition of an environnement "credentials, endpoints, location (region & AZ), compute type (VM, container) and scaling info."

:)

where does the line go for solum, heat and murano ?

ekarlso-, somewhat still to be decided

but solum should be thin

and use what ever makes sense

ekarlso-, we use heat now - but we *could* use murano for services

asalkeld: does the 'build' phase outputs an artifact or a runnable image ?

julienvey, it should be an image

(in glance)

asalkeld: ok, I guess it will produce as many images as there are compute options in environnements ?

one for docker envs, one for vm envs ?

maybe, but I was thinking a seperate build job

I wasn't sure how to refer to the images

ok, If we go with a separate job, we should want to split the build-artifact and build-image phases

julienvey, sure - that is really an optimisation

because we would want the same artifact, built and tested once, be used within multiple images

julienvey, well you might want to test both

(just to make sure)

yes, I was only meaning unit tests

o, the unit tests don't need an image

yes yes

tho' we could have functional tests there

I resisted having an overly complex example

yes, I think you're right. Let's start simple and increment on that later

I prefer having code merged and refactor than over-designing from the beginning

tho' functional tests are "special" as they have a deployment stage as well as testing

(deploy the stack and a test stack, get the result, destroy the stacks)

+1 julienvey totally agree

tho' it gets messy if you have to change the dsl too much

I think functionnal tests are automated and, even if they need compute resources, it should be within the build phase.

acceptance tests need a running env and manual steps

yeah

I need to think about the rest API now

hi, +1 for incremental solution :)

hi stannie

asalkeld: why there isn't "depends_on: build" in deploy goal ?

so many building blocks :/(

stannie, it is just a way of saying - don't run this until x succeeds first

could be something else

asalkeld: ok I see so like build & deploy are two separate step, it doesn't require depends_on

stannie, 'cos they have other dependancies {get_output}