#solum

which will be a good thing for the project

and given our experience with orchestration of flows making heat and nova own these probably is the best outcome for everyone

adrian_otto: sorry, i was saying if heat isn't involved

oh, we are not suggesting that

it's useful to think of heat and it's extension mechanisms (over time) as the better integration point for resources that are more complicated than solum might want to expose, but not exposed via nova

claytonc: i think we need to push back discussion about heat till the docker+nova design sesson

for instance for other legacy systems and their integration

I am simply saying that I'm skeptical about making Heat do things that are in Nova's wheelhouse already

see what comes out of that first

adrian_otto: concretely what things? we're probably on the same page, but want to know what those are in your mind

ok, I'll be sure to attend that one

usage events, integration with other projects like SDN features from Neutron

no disagreement there

things like attaching volumes from Cinder

same - however assumption has to be whether attaching a volume is the abstraction

or whether it's making a mount point available that is located on the host system

we should just carefully consider what are solved problems, and try not to re-solve them elsewhere

yup, not advocating resolving problems at all

i'm probably more concerned about putting concerns into nova that don't belong there

such as some of the higher level abstractions around storage and mount points

esp. shared storage

Did you look at the Shares Service I referenced? Project Manila?

i.e. solum telling heat to do X and Y with Nova makes more sense to me than solum telling heat to ask nova to do a bunch of automated things

that looked like a sensible control plane abstraction for shared storage

yeah i'd seen it before

it did - i couldn't figure out though whether it had anything actually running

or what timeframe it would have such

something to explore!

this is good healthy debate. I like it!

i think you could boil my concern down to "heat is the proper place for orchestration and coordination of resources in openstack - therefore if we need a capability that most closely associated with nova, having heat tell nova to do it is correct. however if the resource is not practical to expose in nova or an existing project, operators/integrators should be doing that through heat vs solum"

although integrating with solum will be necessary for higher control plane concepts

adrian_otto : +1

agree 100%

that leaves us to judge what is practical, but we share the same sentiment, definitely.

yeah practicality worries me a bit

nova and heat have some big items to close out in icehouse and 'j'

right, so we should plan to be nimble and stay involved with those discussions

I do imagine there may be some exceptions for dealing with Heat vs the lower level services. For example: read-only operations seeking detailed status. heat may not even have that information, so we will need to consult the actual low level service to surface something. All changes/updates need to be funneled through Heat though.

adrian_otto: agreed. sensors may be plugins to solum, operations should channel through heat. one thing we've been struggling with is what the right model for that is with heat for arbitrary operations

like if you attach a Sensor to a load balancer instance to get a performance/usage metric

as we've tried to rethink our operation abstraction we still come up with very useful operations that don't feel like the right operations to be talking to via heat

since it's declaritive

if it would result in a change in the heat "stack" resource, then it does need to go through Heat. If it would not cause the stack to change, then we could allow an operation to bypass heat and act on some resource.

like scatter gather

adrian_otto: yeah mirrors my thinking

there are some operations that act on deployment units that are stateful to the system but are not represented in the stack potentially - there are advantages to having the stack model it, but potentially it's the wrong abstraction if updates to the stack would be orthogonal

so for instance key distribution to hosts running DU containers

rollback of a stack is orthogonal to key distribution (if the key state is managed by solum or a plugin to solum)

agreed

adrian_otto: do we have a stackforge project for solum?

it's in the review system. One sec and I will link you to it so you can +1 it

upon merge, the StackForge project will be created

thanks everyone for checking that out

looks like we have consensus for approval

Oh yay, I've been holding back some code for that event. :)

adrian_otto: this is a general comment on CAMP plus integration - what discussion of async process flows has been done. I'm not sure it's a guarantee that the creation of an "application" and it's attendant git repo can be completed in negligible time (under 2s). in camp spec was decision to always subdivide resources into those that can be created rapidly and those that can't, and to make those that can't

have stateful indications of progress?

e.g. - POST application resource, delegate to provision of git repo, time is 20s. should response to client gate on repository being created, esp. if that might be a transient problem or a retry may be required (thinking of standard distributed system problems of reachability and availability and 2p transactions)

any operation can be async

the subjects pertaining to the orchestration are out of scope

what you are looking for is a representationSkew of NONE

clarkb commented that we should make the S in Solum lowercase in the stackforge repo path, so I adjusted that. Now we need a re-review: https://review.openstack.org/53151

(because your votes get cleared upon each change to the patch set)

adrian_otto: done

tx!

claytonc: dmueller ^

done ^

Looks like we made it into stackforge: https://git.openstack.org/cgit/stackforge/solum/

<http://ln-s.net/:O97>; (at git.openstack.org)

gravy

yes, I am working on seeding the ACL now

neat

and inquiring with #openstack-infra about how the initial import works

so who is in the initial group when seeding the ACL? not suggesting i should be, just curious how you decide :)

I will be the seed member

and we will agree in our public meeting who should be added

membership will be handled in accordance with other ecosystem projects

cores vote on adding new cores, removing, etc.

For those who do not know, the difference between a reviewer and a core reviewer is that a core reviewer in combination with another can cause a pull request to be merged in Gerrit

the tradition is that reviewers who are consistently performing reviews and improving the quality of what gets merged are promoted

russellb: sound good?

sure

+1 ^