16:00:12 <adrian_otto> #startmeeting Solum Team Meeting
16:00:15 <openstack> Meeting started Tue Sep  9 16:00:12 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <openstack> The meeting name has been set to 'solum_team_meeting'
16:00:22 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-09-09_1600_UTC Our Agenda
16:00:28 <adrian_otto> #topic Roll Call
16:00:34 <adrian_otto> Adrian Otto
16:00:38 <gpilz> Gilbert Pilz
16:00:40 <muralia> murali allada
16:00:42 <james_li> james li
16:00:44 <datsun180b> ed cranford
16:00:53 <devkulkarni1> Devdatta Kulkarni
16:00:53 <mkam> Melissa Kam
16:00:57 <noorul> Noorul Islam
16:01:12 <roshanagr> Roshan Agrawal
16:01:25 <julienvey> Julien Vey
16:01:57 <adrian_otto> hello everyone
16:01:59 <stannie> Pierre Padrixe
16:02:29 <AnishKarmarkar> Anish Karmarkar
16:02:32 <adrian_otto> so first some small talk… Pierre and Julien...
16:02:45 <adrian_otto> in France, are telemarketers allowed to call your cell phones?
16:03:03 <adrian_otto> and if you do get a call, is there anything you can do? Any recourse?
16:03:18 <julienvey> yes, they can
16:03:41 <julienvey> and for phone call I don't know if we can do anything
16:03:59 <stannie> I really don't know
16:04:02 <adrian_otto> Americans get irritated when they get unsolicited calls on their mobile phones
16:04:18 <noorul> so does everyone :)
16:04:19 <datsun180b> That's probably in part due to the fact that we're charged for incoming calls
16:04:20 <roshanagr> It is no different in India
16:04:22 <adrian_otto> to such an extent that we have laws against it
16:04:27 <stannie> we usally don't do anything :(
16:04:34 <dimtruck> Dimitry Ushakov
16:04:39 <adrian_otto> interesting, ok.
16:04:58 <adrian_otto> Anyone else who would like to be recorded in attendance, please chime in at any time
16:05:08 <adrian_otto> #topic Announcements
16:05:09 <gpilz> as a public service, you should keep them on the phone as long as possible - then don't buy anything
16:05:16 <adrian_otto> any announcements from teammembers?
16:05:26 <adrian_otto> gpilz: :-)
16:06:12 <adrian_otto> #topic Review Action Items
16:06:15 <adrian_otto> (none)
16:06:26 <AnishKarmarkar> not for cell phones but if you use voip, forward them to Lenny (http://www.itslenny.com/)
16:06:32 <adrian_otto> #topic Blueprint/Task Review
16:06:44 <adrian_otto> Anish, that's brilliant!
16:07:17 <noorul> where is the bot which shortens the link?
16:07:39 <adrian_otto> #link http://www.itslenny.com/
16:07:54 <adrian_otto> hummm, maybe that is not turned on in this channel
16:08:24 <adrian_otto> ok, any feature development work, tasks, or bugs that anyone would like to raise for group discussion?
16:08:53 <gpilz> I really need to get this reviewed:
16:08:55 <gpilz> https://review.openstack.org/#/c/117056/
16:09:03 <noorul> I have a question, but I think I should leave it for Open Discussion
16:09:05 <gpilz> I've got other work in the pipeline that depends on it
16:09:17 <gpilz> a schedule, and a boss breathing down my neck
16:09:23 <noorul> 1818 lines
16:09:28 <adrian_otto> Gil, thanks for raising that
16:09:49 <adrian_otto> yes, it is a big patch which makes it difficult to review quickly
16:09:55 <julienvey> gpilz: will take a look, but you can still create other patches on top of that one
16:10:02 <gpilz> noorul - it looks like a lot, but there isn't a lot of complexity there
16:10:04 <adrian_otto> I have sat down to look at it, and got distracted with other tasks before finishing more than once
16:10:08 <datsun180b> it's mainly structure
16:10:08 <PaulCzar> I would like to see this reviewed and merged in,  fixes problems with 14.04 ( the gate, etc ) - https://review.openstack.org/#/c/119391/
16:10:32 <adrian_otto> so in the future, consider submitting groups of patches that are smaller
16:11:32 <adrian_otto> ok, let's take a moment to review each of those now
16:11:40 <noorul> ok, its approved
16:12:21 <adrian_otto> ok, so 119391 has been processed
16:12:37 <datsun180b> nice
16:12:41 <adrian_otto> so now we have 117056
16:12:45 <datsun180b> that means we get one more green gate
16:12:49 <gpilz> thanks
16:13:20 <adrian_otto> Gil, I have some comments on your patch
16:13:30 <gpilz> okay
16:13:31 <adrian_otto> so I'll make those and follow up with you after we adjourn
16:13:32 <devkulkarni1> gpliz: by moving assemblies to camp/v1_1
16:13:37 <devkulkarni1> the client will break
16:13:52 <gpilz> I haven't moved v1/assemblies
16:13:52 <james_li> datsun180b: after a while we can consider make trusty ‘vote'
16:14:04 <devkulkarni1> btw, I will  also review the patch in detail later
16:14:13 <devkulkarni1> gpliz: oh okay
16:14:14 <noorul> Why are we not improving v1 ?
16:14:16 <datsun180b> i hope "a while" is "about two hours"
16:14:21 <noorul> Did we release v1 yet?
16:14:28 <gpilz> if you read the spec for Solum CAMP, you will see that the intention is to no affect Solum clients in any way
16:14:45 <devkulkarni1> +1
16:14:51 <adrian_otto> noorul: do you mean v1 of Solum?
16:15:14 <datsun180b> it's just an orthogonal way to present and manipulate the extant resources from what i understand
16:15:27 <noorul> Yes,
16:15:33 <noorul> is v1_1 for CAMP
16:15:38 <noorul> then where is solum version?
16:15:53 <julienvey> i think v1 is the api version, not solum
16:15:53 <gpilz> Solum is …/v1/foo
16:16:02 <gpilz> CAMP is camp/v1_1/foo
16:16:03 <adrian_otto> noorul: good question. "CAMP 1.1" is the OASIS spec version currently in 2nd public review
16:16:07 <noorul> Yeah, I mean solum api version
16:16:10 <adrian_otto> it is not pinned to Solum's versioning
16:16:23 <datsun180b> i think v1_1 tracks only camp and has no deference to solum's own versions
16:16:28 <adrian_otto> v1 was submitted to OASIS like 2 years ago
16:16:31 <gpilz> and you can turn CAMP off
16:16:37 <adrian_otto> but was not proposed as a standard
16:16:48 <adrian_otto> 1.1 will be the first public standard version
16:17:31 <adrian_otto> noorul: does all that make sense?
16:17:37 <noorul> to which version of solum api does this tied to?
16:18:04 <datsun180b> none of them
16:18:04 <adrian_otto> v1
16:18:12 <adrian_otto> but it's another API
16:18:18 <adrian_otto> not just a fascade
16:18:26 <datsun180b> camp's versions will increment whenever oasis wants it to
16:18:36 <datsun180b> regardless of solum's version march
16:18:44 <adrian_otto> correct, datsun180b
16:19:37 <adrian_otto> noorul: clear now?
16:19:48 <noorul> The structure confuses me
16:19:54 <noorul> should that be in solum/camp ?
16:20:03 <noorul> rather than in solum/api/controller/..
16:20:20 <adrian_otto> (that was one of the things I flagged for comment)
16:20:35 <gpilz> noorul - I need to leverage the existing Pecan controller tree
16:21:02 <gpilz> so I start at the root of Solum - the '/' in '/v1'
16:21:16 <gpilz> that's the perfect place to enable/disable CAMP support
16:21:42 <gpilz> if you disable camp, the root controller just never sees the 'camp' controller - and you get a 404
16:23:42 <devkulkarni1> and python-solumclient does not need to change because it is not supposed to support the camp endpoints
16:23:55 <gpilz> right
16:24:40 <gpilz> also - i need to leverage the unauthenticated access support in solum/api/auth.py
16:25:05 <devkulkarni1> for which part?
16:25:09 <gpilz> because the resources that describe which CAMP versions are supported should be available to unauthenticated clients
16:25:15 <adrian_otto> platform endpoints
16:25:18 <noorul> why do you think you cannot import from solum.api in camp.api ?
16:25:42 <devkulkarni1> gpilz, adrian_otto: ok make sense
16:26:16 <adrian_otto> devkulkarni1: the other reason is for automated version discovery
16:26:22 <gpilz> noorul - it's not a matter of importing - I want to share a single pecan instance
16:28:14 <kebray> gpilz are you asking for solum-camp API to share same single running instance of pecan as non-camp-solum api?
16:29:25 <gpilz> yes - if you read the Solum CAMP spec you will see that it requires cross-compatibility
16:29:57 <gpilz> if you create a plan using the CAMP API, that plan should be visible via the Solum API (authorization policy allowing)
16:29:59 <adrian_otto> kebray: gpilz is referring to the spec in the solum-specs repo for this feature
16:30:17 <gpilz> similarly, if you create a plan via the Solum API, it should be visible in the CAMP API
16:30:45 <datsun180b> #link https://review.openstack.org/#/c/112153/
16:30:57 <gpilz> the easiest way to do this is share a single pecan instance
16:31:01 <devkulkarni1> thanks datsun180b
16:31:06 <roshanagr> is cross compatibility a requirement?
16:31:08 <adrian_otto> #link http://git.openstack.org/cgit/stackforge/solum-specs/tree/specs/juno/solum-camp-api.rst
16:31:20 <gpilz> roshangar - yes, we don't want to split our user base
16:31:23 <datsun180b> either way, i linked the review of the merged code
16:31:38 <gpilz> CAMP is just an alternate API to the same underlying services
16:31:55 <noorul> so the spec is already in
16:32:00 <datsun180b> right
16:32:01 <gpilz> yes
16:32:31 <roshanagr> gpilz: how does now having cross compatibility split the user base
16:32:49 <roshanagr> as long as a user picks one API and sticks with it, he should be good
16:32:49 <adrian_otto> the lack of compatibility would drive a split
16:32:59 <gpilz> you force users to pick which API they are going to use forever more
16:33:25 <gpilz> either that or force them to move there apps from the Solum flavor to the CAMP flavor or vice versa
16:33:40 <kebray> adrian_otto, then if that's the argument, why not argue for one and one API?   Why have two with intention of no split?  That implies they should be made the same.
16:33:44 <roshanagr> we give users a choice in the beginning, and once they have made the choice, they stick with that choice.
16:33:49 <gpilz> we want a "many tools / one system" model not a "many systems" model
16:34:04 <roshanagr> what is the overhead of cross compatibility?
16:34:20 <adrian_otto> kebray: solum will effectively be an extended version of CAMP 1.1, but will not be required to follow the spec if it does not align with the goals of the project
16:34:25 <gpilz> roshanagr - there isn't any that i have seen (so far)
16:34:42 <adrian_otto> our community is reluctant to track API's to specifications, so this is the compromise
16:35:20 <devkulkarni1> +1 adrian_otto .. also, if some other specs come along and want to provide a different 'view' of underlying resources I think it should be okay
16:35:26 <roshanagr> gpilz: good to know, thanks.
16:35:28 <kebray> +1 for not tracking the solum API to a spec.
16:35:47 <adrian_otto> with our current approach we don't limit Solum's freedom, and we open the possibility that CAMP compliant clients can use Solum
16:36:44 <kebray> by tying camp API to same instance of pecan, won't that limit Solum's freedom in terms of solum API evolution vs. camp standard (where we are acknowledging we don't want them to be tied).
16:37:06 <gpilz> kebray - the Solum API is free to do whatever it wants
16:37:10 <adrian_otto> that's a slippery slope
16:37:12 <gpilz> the onus is on me to keep up
16:37:27 <adrian_otto> gpilz: well put
16:37:56 <devkulkarni1> kebray: not really. it will be upto each 'view' implementor's responsibility to make sure that their stuff does not break Solum engine
16:38:01 <adrian_otto> it CAMP became an obstacle for Solum, and it's contributors for the CAMP related code are unavailable or unwilling to adapt it, then it could be deprecated.
16:38:11 <adrian_otto> s/it CAMP/if CAMP/
16:38:32 <gpilz> adrian - that's one reason I allow CAMP support to be disabled with a single-line config change
16:38:33 <noorul> kebray: I have the same concern
16:39:17 <adrian_otto> my advice is not to worry too much about this until it materializes as a problem
16:39:21 <kebray> adrian_otto, seems deprication/maintenace would be easier if it's a separate API instance (tests aren't tied to same running instance,so separate concerns)... also better for the solum service operator too to understand and run.
16:39:25 <devkulkarni1> noorul, kebray: so how do you think this concern can be addressed?
16:39:34 <adrian_otto> worst case we update solum to remove problematic code.
16:39:54 <adrian_otto> best case, we evolve them in a coordinated way
16:40:11 <adrian_otto> I don't think we are going to have major API changes
16:40:16 <AnishKarmarkar> given the cross-polination between Solum and CAMP (not to mention common participants), what is the likelihood that they'll diverge enough to be incompatible?
16:40:33 <adrian_otto> most of the future features will manifest as additions to the DSL, not thew API
16:40:52 <AnishKarmarkar> s/polination/pollination/
16:41:13 <adrian_otto> AnishKarmarkar: I doubt it will be a barrier
16:41:37 <kebray> devkulkarni1, have camp run as a separate API instance/endpoint, using under the hood public and/only public API calls to Solum where possible.. if something can't be done via public solum API call, then CAMP and Solum aren't align, and for each feature a discussion needs to be had.
16:41:39 <noorul> we started with camp
16:41:51 <noorul> then we had issues, explored workflow
16:42:02 <roshanagr> gpilz: will I be correct to think that the need to share same instance of pecan is driven by need for cross compatibility?
16:42:07 <adrian_otto> most concerns on this subject assume that standards organizations and software development efforts are not in any way coordinated.
16:42:12 <adrian_otto> in this case they actually can be.
16:42:44 <gpilz> roshanagr: yes
16:42:47 <adrian_otto> noorul: those issues were not with ALM
16:42:57 <adrian_otto> they were with workflow, which CAMP is not designed for.
16:43:34 <AnishKarmarkar> keep in mind that the exit criteria for CAMP (any version) is that there be multiple compatible implementation. So in the future, if CAMP does something that can't work with Solum, I doubt it will make it to the final spec
16:43:59 <roshanagr> gpilz: thanks. so cross compatibility does increase the coupling between Solum and CAMP API. Which is where I ask to evaluate the cost benefit of cross compatibility
16:44:37 <roshanagr> We can still have CAMP as an alternate API on Solum, without having tigher coupling or cross compatibility
16:44:45 <roshanagr> tighter
16:44:50 <gpilz> roshanag: keep in mind that it isn't necessarily a single user that is being affected
16:45:03 <noorul> i think 15 minutes more left
16:45:12 <noorul> I have question
16:45:30 <gpilz> if a group of people are working on an application together - you would like to allow each person to use the tools that suit them best
16:45:43 <noorul> adrian_otto: i still remember you saying that RAX is using solum internally
16:45:51 <noorul> adrian_otto: Is there a documentation on that?
16:46:21 <adrian_otto> noorul: only my statements in the announcement section of that meeting where it was mentioned
16:46:23 <devkulkarni1> kebray: sure that is a possibility. it will mean anyone who wants to provide alternative views would not be directly leverage Solum models. may be it might be okay to do that when the view is so different that it will need its own models anyways.
16:46:25 <roshanagr> gpilz: we could have an organization/group discuss and arrive at a single preferred answer to which API they prefer
16:47:04 <gpilz> roshanagr: why make them do that?
16:47:50 <adrian_otto> noorul: I'm happy to follow up with you to give you additional perspective.
16:47:56 <noorul> adrian_otto: ok
16:48:09 <devkulkarni1> roshanagr: reaching such a consensus would be difficult in most cases (different orgs/groups have different needs)
16:48:20 <roshanagr> gpilz: it is a workable compromise between flexibility for the user and implementation separation of concerns
16:49:24 <roshanagr> devkulkarni: yes, however for a given group, it is fine to expect them to arrive at a concensus. Unless we feel the cost of cross compatibility is so low that this is a non issue
16:49:29 <adrian_otto> ok, so in a moment I will bring us to Open Dicussion
16:50:25 <adrian_otto> I think it's worth making an action item to address open concerns regarding the tactical addition of CAMP API support. We can do that as a follow-up IRC meeting.
16:50:31 <adrian_otto> does that sound fair?
16:50:46 <gpilz> sounds fair to me
16:50:46 <devkulkarni1> +1
16:50:49 <roshanagr> adrian_otto: yes, sounds good
16:51:00 <devkulkarni1> I would suggest postpone it to the meeting when adrian_otto you will be around
16:51:29 <kebray> +1
16:51:57 <adrian_otto> #action adrian_otto to schedule an IRC meeting for discussion of CAMP API support, and our tactical integration options.
16:52:20 <adrian_otto> look for an ML thread with a link to a poll for selecting the date/time
16:52:27 <adrian_otto> thanks
16:52:33 <adrian_otto> #topic Open Discussion
16:52:53 <roshanagr> got to go, thanks
16:53:02 <adrian_otto> roshanagr: cheers
16:53:13 <adrian_otto> any other topics for today?
16:54:00 <datsun180b> whoo, cz's patch merged
16:54:08 <adrian_otto> :-)
16:54:16 <datsun180b> can we make the trusty gate voting now? should we?
16:54:36 <adrian_otto> datsun180b: good question
16:55:03 <PaulCzar> we should let it bake for a few weeks
16:55:11 <adrian_otto> do we expect most of Solum's user base to be using trusty as their environment for running Solum? If so, then it makes sense to gate on it.
16:55:27 <datsun180b> well i know i've got problems with my 12.04 vm right about now
16:56:23 <adrian_otto> PaulCzar: I'm happy to leave it as non-voting until we feel confident. I worry about it becoming an impediment to getting code in.
16:57:09 <datsun180b> okay so it bakes
16:57:11 <noorul> adrian_otto: yes and then we have to wait for infra :)
16:57:14 <datsun180b> for how long?
16:57:27 <adrian_otto> noorul: yes, indeed.
16:57:40 <adrian_otto> datsun180b: we can revisit it next week?
16:57:52 <noorul> There is one advantage
16:58:03 <noorul> it will be -1 jenkins job
16:58:03 <datsun180b> sgtm
16:58:28 <noorul> may be the feedback from jenkins will be faster if we could remove fedora one
16:59:08 <adrian_otto> noorul: yes, that's possible, although I think they run in parallel.
16:59:22 <noorul> adrian_otto: what is the benefit?
16:59:29 <adrian_otto> in tha case it would only help if the fedora test were the longest.
16:59:56 <adrian_otto> from a performance perspective.
17:00:08 <noorul> adrian_otto: What is the benefit of having two jobs
17:00:15 <adrian_otto> I'm happy to drop it if we have at least one popular OS doing gate.
17:00:25 <noorul> +1
17:00:27 <adrian_otto> thanks everyone for attending today
17:00:32 <adrian_otto> #endmeeting