16:01:42 <adrian_otto> #startmeeting Solum Team Meeting
16:01:42 <openstack> Meeting started Tue Dec 10 16:01:42 2013 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:45 <openstack> The meeting name has been set to 'solum_team_meeting'
16:01:51 <adrian_otto> #topic Roll Call
16:01:57 <paulmo> Paul Montgomery, Rackspace
16:01:58 <funzo> Chris Alfonso, Red Hat
16:01:58 <adrian_otto> hello everyone
16:02:05 <funzo> good morning
16:02:09 <datsun180b> hi there
16:02:09 <russellb> Russell Bryant, OpenStack
16:02:13 <jwforres> Jessica Forrester
16:02:16 <gokrokve_> Georgy Okrokvertskhov
16:02:19 <coolsvap> Swapnil
16:02:21 <devkulkarni> Devdatta
16:02:24 <claytonc> Clayton
16:02:48 <kgriffs> Kurt
16:03:11 <adrian_otto> welcome everyone
16:03:14 <adrian_otto> #topic Agenda
16:03:14 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum Today's Agenda
16:03:24 <adrian_otto> #topic Announcements
16:03:27 <briancline> Brian Cline / SoftLayer
16:03:32 <adrian_otto> Are there any announcements the team members would like to make?
16:04:05 <adrian_otto> ok, to blueprints
16:04:07 <adrian_otto> #topic Review Blueprints
16:04:14 <adrian_otto> #link https://launchpad.net/solum/+milestone/milestone-1 Milestone 1 Blueprints
16:04:21 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/api Solum API
16:04:36 <adrian_otto> Note: I'd like to timebox this to ~10 minutes. We can schedule a breakout for a longer Q&A if there is interest.
16:04:43 <adrian_otto> Status: Drafting Plan design proposal
16:04:51 <adrian_otto> #link Draft WIP: https://etherpad.openstack.org/p/solum-demystified
16:05:20 <adrian_otto> we can take a moment to look that Etherpad over and collect feedback on the file and resource for the Plan
16:06:07 <adrian_otto> I recognize we will need more than just a couple of minutes to dig in and understand everything here
16:06:40 <adrian_otto> so feel free to mark up the etherpad with your remarks and questions
16:06:41 <devkulkarni> adrian_otto: yes, its big. (and excited to see this)
16:06:55 <claytonc> yeah, same
16:07:03 <devkulkarni> one quick question: what is 'origin' in a plan?
16:07:04 <adrian_otto> devananda: thanks. I look forward to working through this with you this week
16:07:19 <adrian_otto> origin is where the plan came from, such as "Solum Model Interpreter"
16:07:30 <adrian_otto> or "Adrian's Platform Hosting"
16:07:52 <adrian_otto> in the case where you have a plan that was created on one system, and exported to another, you want some label that can indicate where it was produced
16:08:08 <devkulkarni> ah okay.
16:08:19 <gpilz1> also helps platforms recognize "their own" plans
16:08:55 <devkulkarni> great to see the build service in the 'services' section :)
16:10:01 <adrian_otto> yes, you can even get to a point where there is no language pack at all, just a service for "Python Build" for example
16:10:10 <adrian_otto> and the language pack selection can be implicit
16:10:31 <devkulkarni> about component type, would it be useful to identify the specific kind of component (e.g.: db, or ip-handler)
16:10:48 <devkulkarni> this is not related to the current bp probably, but just thinking out loud
16:10:50 <rajdeep> should there be auto detection of the app type
16:10:58 <rajdeep> in case nothing is specified
16:11:05 <adrian_otto> oh, a component is extensible, so we can add any number of attributes to it
16:11:36 <adrian_otto> basically in the scheme I'm proposing anything prefixed with solum_ can go into basically any resource anywhere
16:12:54 <devkulkarni> I see. So instead of defining a generic 'attributes' map or something, we will introduce attributes that start with 'solum_' as and when we need.
16:13:13 <adrian_otto> ok, so take just a few more minutes, and we will skip forward to discussing the status of CLI
16:13:40 <adrian_otto> devananda: Yes, that's how the Extensions will work
16:14:03 <adrian_otto> it allow for *anything* to be added as long as it does not contradict the base functionality
16:14:19 <adrian_otto> that allows different service providers to surface different features
16:14:28 <adrian_otto> but in a way that won't clash
16:14:33 * devananda perks up
16:14:35 <adrian_otto> so if Rackspace wanted a foo attribute
16:14:46 <adrian_otto> we could have rax_foo on there
16:14:58 <adrian_otto> as an Extension loaded in our Solum setup
16:15:06 <adrian_otto> make sense?
16:15:11 <russellb> devananda: tab completion fail i think
16:15:28 <adrian_otto> but if you put vendor specific stuff into your plans, then you can't expect your plan to be portable
16:15:50 <devananda> russellb: it seems that way :)
16:15:51 <devkulkarni> adrian_otto: yeah, makes sense
16:15:58 <adrian_otto> ok, so please get me additional feedback, and ML follow-up as needed to continue to advance on this topic
16:16:13 <devkulkarni> russellb: I think that is what must be happening :)
16:16:34 <adrian_otto> did I miss something important?
16:16:46 <devkulkarni> nah, nothing.
16:16:51 <coolsvap> devkulkarni :)
16:16:55 <adrian_otto> oh, you had me worried for a sec
16:17:26 <adrian_otto> oh, whoops, that was tab completion. Sorry devkulkarni
16:17:37 <devkulkarni> he he.. no worries :)
16:17:37 <adrian_otto> sorry devananda
16:17:52 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-minimal-cli Command Line Interface For Solum (devdatta-kulkarni)
16:18:05 <devkulkarni> Okay. So here is a brief update.
16:18:24 <devkulkarni> •	Looked at the Trove cli; Plan to use this as starting point: https://github.com/openstack/python-troveclient/tree/master/troveclient/compat
16:18:25 <devkulkarni> •	Next step is to look at cliff (https://github.com/dreamhost/cliff) and see how that can be used.
16:18:57 <devkulkarni> datsun180b has helped us with understanding the Trove cli
16:19:33 <devkulkarni> datsun180b: thanks for the help
16:19:35 <kgriffs> devkulkarni: how will this play into the effort to create a single CLI for openstack projects?
16:19:58 <kgriffs> I suppose since solum is not even incubated yet, it may not (play into it) yet
16:20:03 <devkulkarni> kgriffs: good question. haven't thought that through yet.
16:20:28 <adrian_otto> kgriffs: I atually met with DRG about that last week.
16:20:32 <devkulkarni> open to suggetions/feedback on whether we should be targeting that from M1
16:20:50 <kgriffs> adrian_otto: cool
16:20:51 <adrian_otto> we are looped in and Jesse Noller will be subscribing to our review stream
16:21:15 <adrian_otto> so since he is driving our overall OpenStack alignment efforts, we will ride his coattails on that
16:21:24 <kgriffs> makes sense
16:21:31 <adrian_otto> and he will inform us as progress is made on the OpenStack SDK efforts
16:21:38 * kgriffs grabs onyo Jesse's coattails
16:21:46 <kgriffs> s/onyo/onto
16:21:46 <russellb> who is DRG?
16:21:49 <adrian_otto> we can invite him to this meeting for periodic updates
16:21:52 <devkulkarni> cool. adrian_otto, will keep an eye out for updates about this frm you
16:22:08 <sapuri> devkulkarni: besides the app create-delete commands, are the rest of the app lifecycle commands in scope for m1 - e.g. app start / stop /restart etc?
16:22:13 <kgriffs> russellb: Rackspace
16:22:16 <adrian_otto> russellb: It's our Developer Relations Group. They make tools for Rackspace customers, and are contributing to OpenStack
16:22:34 <adrian_otto> they are interested in helping unify the OpenStack CLI
16:22:39 <russellb> ok
16:22:53 <russellb> should talk to whoever is working on the unified CLI project too :)
16:23:05 <adrian_otto> I will connect you with Jesse
16:23:08 <russellb> maybe they are, just got confused when you switched to rax talk
16:23:18 <adrian_otto> they are planning some more ML discussion too, that that's coming soon
16:23:28 <adrian_otto> russellb: sorry about that.
16:23:30 <devkulkarni> sapuri: its not set in stone. if we are done with the create/delete, we will pull in the rest
16:23:35 <kgriffs> I guess I assumed Jesse was already in touch with doug et al. on that
16:23:42 <russellb> probably is
16:23:46 <adrian_otto> kgriffs: yes
16:24:11 <adrian_otto> ok, more discussion on CLI, or should we advance to Git?
16:24:29 <datsun180b> my two cents is maybe focus stays on minimal and if/when general OS direction is decided, move toward that goal
16:24:46 <adrian_otto> datsun180b: that's exactly the approach
16:24:53 <adrian_otto> we will work entirely in parallel
16:25:00 <adrian_otto> until we have things to converge on
16:25:05 <datsun180b> plenty of time to vet cliff or other unified approaches
16:25:06 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-git-pull Pull integration of Solum from an external Git repo (kraman)
16:25:20 <kraman> Hi, so summary of out last meeting:
16:25:39 <kraman> We agreed that the git workflow would be configurable and will be logged and auditable
16:26:05 <kraman> there would also be a configuration allowing ops to specify a regex for allowed URLs
16:26:13 <kraman> so they may restrict it as they see fit
16:26:25 <kraman> There was discussion around using Zuul
16:26:46 <kraman> and I am hoping to meet up with mordred later to get a diagram of his thoughts on that
16:26:57 <mordred> sorry. it's my fault
16:26:58 <kraman> our next meeting is scheduled for tomorrow at 8 am PST
16:27:01 <mordred> I owe documentation
16:27:11 <mordred> two conferences in a week happened
16:27:12 <kraman> and thats where we stand right now
16:27:29 <kraman> mordred: no problem. if you have time today we can discuss it before tomorrows meeting
16:27:29 <paulczar> I assume zuul would be optional ?
16:27:30 <adrian_otto> kraman: thanks
16:27:38 <mordred> but I promose - when I get it done, you'll all love it and we can all go raise bunnies or somehting :)
16:27:47 <adrian_otto> mordred: lol
16:27:48 <mordred> paulczar: I don't think so
16:27:53 <kraman> paulczar: we havent decided on it yet. still needs discussion
16:28:09 <kraman> but right now it feels like it would not be optional
16:28:25 <adrian_otto> ok, ready for next blueprint?
16:28:25 <kraman> there are other questions I had as well which I have sent on the ML
16:28:32 <kraman> adrian_otto: yes. thanks
16:28:37 <mordred> yeah. we'll get more deets. sorry for the delay
16:28:38 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/user-authentication User authentication for incoming requests (gokrokvertskhov)
16:28:48 <adrian_otto> See: https://review.openstack.org/58811
16:28:52 <rajdeep_> can we assume other workflow engines can be plugged in as well
16:29:06 <gokrokve_> Hi. I added a new patch set for it. Now it passed gates.
16:29:15 <adrian_otto> gokrokve_: WHOOT
16:29:33 <adrian_otto> ok, so note to reviewers to have a look at that patch set and make remarks
16:29:37 <russellb> gokrokve_: cool, will try to review today
16:29:38 <gokrokve_> It has some small tricks for python33 in test_auth
16:29:52 <adrian_otto> gokrokve_: can you explain them for us here?
16:29:56 <russellb> gokrokve_: do you have a functional test for it?
16:30:13 <gokrokve_> if import of keystone fails, all tests will be skipped
16:30:16 <russellb> gokrokve_: need to get the gate running the functional tests soon (so far it's just starting up the API in devstack)
16:30:40 <gokrokve_> russellb: there is no functional tests for that. Only unit tests.
16:30:58 <russellb> OK, that'd be something nice to add ... can be another patch though, i suppose
16:31:14 <briancline> cool
16:31:36 <adrian_otto> gokrokve_: thanks for the work in thinking through unit+func tests
16:31:40 <gokrokve_> russellb: but this patch affects all functional tests. Authentication is enabled by default, so you need to have keystone and credentials to run tests against app.
16:31:53 <russellb> right
16:31:53 <adrian_otto> and russellb for his contributions there too
16:32:40 <adrian_otto> gokrokve_:  (unless your func tests sets up auth to be False as the stest is stood up, right)?
16:32:54 <gokrokve_> adrian_otto: yes. you can do this.
16:33:06 <adrian_otto> so that would be acceptable for non-auth related func tests
16:33:07 <russellb> would like to start requiring functional tests for everything in the APi as things come in though
16:33:21 <adrian_otto> russellb: +1
16:33:34 <adrian_otto> ok, more remarks on this one?
16:33:35 <devkulkarni> russellb: +1
16:33:36 <gokrokve_> russellb: As soon as we have all required infrastructure around that.
16:33:48 <russellb> well, should be able to do it now
16:33:52 <russellb> they're just not running in the gate yet
16:33:54 <russellb> close though
16:33:58 <gokrokve_> russellb: We need to keep base configuration somewhere.
16:34:47 <adrian_otto> good discussion. Maybe this needs a blueprint?
16:35:23 <adrian_otto> I'll entertain one for that, if someone feels like drafting one.
16:35:32 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/specify-lang-pack Specify the language pack to be used for app deploy (devdatta-kulkarni)
16:35:34 <gokrokve_> adrian_otto: Sure. We need couple bps to organize tests and processes around them.
16:35:42 <sapuri> gokrokve: is the intent to also leverage the notion of tenancy that comes with openstack/keystone,
16:36:06 <gokrokve_> sapuri: Yes. I am thinking about that. It will be a separate BP.
16:36:11 <devkulkarni> Here is an update on the specify-lang-pack bp:
16:36:23 <devkulkarni> •	Status: Had discussion in language pack working group meeting; came up with https://etherpad.openstack.org/p/Solum-Language-pack-json-format
16:36:23 <devkulkarni> •	Status: Need input on the endpoint (/v1/language-packs/ vs. /v1/components/)
16:36:33 <gokrokve_> sapuri: We need to design some unified approach wich works with and without keystone auth.
16:37:07 <devkulkarni> To give a overall context, we agreed to have a API for language packs in M1 in Solum
16:37:33 <devkulkarni> There was discussion around whether we should skip it and directly use glance (or heater) apis for this.
16:37:44 <adrian_otto> devkulkarni: the /services might be where we want to list language packs, or possibly in a catalog service, which has been a topic of discussion on the ML
16:37:53 <claytonc> catalog service was exactly what got discussed :)
16:37:57 <devkulkarni> We agreed that in the background Solum may use glance/heater etc. but API should be built in Solum
16:38:03 <devkulkarni> claytonc: right
16:38:08 <briancline> I hate to add a third option to think about, but perhaps "kits"?
16:38:09 <adrian_otto> got it
16:38:21 <adrian_otto> briancline: ooh, I like that!
16:38:33 <devkulkarni> adrian_otto: /services makes sense
16:39:03 <sapuri> gokrokve: got it.. the authz portions of keystone are limited, but can be built upon using various roles.. the permissions for the roles would have to be maintained in solum db, i would assume
16:39:27 <devkulkarni> I have started working on this, will have a patch sometime soon.
16:39:27 <adrian_otto> ok, next blueprint...
16:39:38 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/logging Logging Architecture (paulmo)
16:39:43 <adrian_otto> See: https://wiki.openstack.org/wiki/Solum/Logging
16:40:13 <paulmo> Ah, beat me to the 2nd link.  The 2nd link contains some guidance for how to log and what to watch out for.
16:40:27 <paulmo> This will be expanded and I will add more explanation in there.
16:40:44 <paulmo> Does this look reasonable to everyone?
16:41:15 <russellb> paulmo: more code expected?  or firming up guidelines?
16:41:33 <adrian_otto> how does the team feel about making the OpenStack Security Guide (OSSG) the basis for the Solum security architecture?
16:41:44 <claytonc> +!
16:41:46 <paulmo> This is attempting to set a process for logging.  Clayton showed how Oslo log can be used to identify confidential data.
16:41:46 <claytonc> +1
16:41:56 <devkulkarni> paulmo: in the 'extra' section, we would need both 'key' and 'value', right?
16:42:08 <russellb> heh, OSSG is also the acronym for the OpenStack Security Group
16:42:08 <devkulkarni> I think there might be a typo "value=value"
16:42:09 <adrian_otto> with some additioanl solum specific concerns added as justified by this team
16:42:16 <paulmo> In the example, key wasn't confidential.   Perhaps a better name would be appropriate for the example though.
16:42:17 <russellb> seems fine though
16:42:47 <adrian_otto> paulmo you said you were going to dress up the examples a bit, so I think that's a WIP, right?
16:42:52 <paulmo> Ok, no concerns about the logging guidelines? I would like to use that in reviews going forward.
16:42:55 <paulmo> Yes
16:43:12 <paulmo> I will modify based on all feedback received. :_
16:43:13 <paulmo> :)
16:43:23 <adrian_otto> ok, any objections to documenting an agreement: "OpenStack Security Guide (OSSG) will be the basis for the Solum security architecture"
16:43:24 <adrian_otto> ?
16:43:51 <russellb> don't think i've read it all, but i'm sure it's sane :)
16:43:52 <paulmo> I think that is a perfect start to architecting our security model.
16:44:01 <devkulkarni> russellb: same here.
16:44:13 <adrian_otto> ok, I'm happy to revisit this later if we find something ridiculous in there
16:44:24 <devkulkarni> sounds good
16:44:24 <paulmo> If we agree to go in that direction, I would create a list of Solum security topics vs operator security implementation and get agreement fromt he group if that sounds like a feasible path.
16:44:33 <russellb> if something ridiculous was in there, it'd be an issue bigger than just solum's concern, heh
16:44:36 <devkulkarni> paulmo: +1
16:44:45 <adrian_otto> plus, we are participating in the OSSG, so we can get it changed if we find something that we truly can't accept
16:44:50 <russellb> i think every project should be on board with what's in there, and should contribute as applicable
16:44:53 <adrian_otto> russellb: exactly
16:45:09 <paulmo> russellb: Yes, I plan to contribute to the spec where we find new Solum issues.
16:45:09 <adrian_otto> #agreed OpenStack Security Guide (OSSG) will be the basis for the Solum security architecture
16:45:25 <coolsvap> no objections as long as #Solum follows the #OpenStack way from start :)
16:46:00 <adrian_otto> #agreed Solum will have additional security requirements as needed, documented on our Wiki pages
16:46:19 <adrian_otto> (as security concerns pertain to applications)
16:46:22 <russellb> coolsvap: +1, and alternatively, work to influence the OpenStack way instead of just diverging without broader conversation when applicable
16:46:45 <paulmo> Here is the link to the addition Solum-specific requirements (to be, need to clean up vs the OSSG): https://wiki.openstack.org/wiki/Solum/Security
16:46:45 <adrian_otto> our last blueprint was mentioned earlier, so this should be a quick update:
16:46:52 <rajdeep_> +1 on using the standard OSSG with additional layers where ever applicable
16:47:11 <rajdeep_> containers / docket
16:47:19 <adrian_otto> #link https://wiki.openstack.org/wiki/Solum/Security
16:47:25 <adrian_otto> (for the minutes)
16:47:32 <rajdeep_> docker could be one area where additional hardening is required
16:47:49 <adrian_otto> rajdeep_: absolutely
16:47:50 <paulmo> Yes, agreed rajdeep_
16:47:58 <adrian_otto> last blueprint now...
16:48:00 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-zuul-integration Solum integration with Zuul (devdatta-kulkarni)
16:48:01 <devkulkarni> actually, for update on the last bp, we can just wait for mordred to send the flow/diagram for Zuul.
16:48:11 <adrian_otto> ok, so no update needed
16:48:16 <adrian_otto> #topic Open Discussion
16:48:29 <kraman> devkulkarni: is that BP just a seb BP of the git workflow
16:48:40 <funzo> also, waiting for responses to krishna's email re Zuul
16:48:57 <kraman> s/seb/sub/
16:49:00 <claytonc> adrian_otto: as per the langpack meeting yesterday there's a spec missing from M1 that we said would be essential
16:49:05 <claytonc> which was langpack-examples
16:49:06 <devkulkarni> devkulkarni: it is a separate bp than git workflow. I had created it as a placeholder for investigating Zuul.
16:49:15 <devkulkarni> sorry I meant kraman
16:49:17 <devkulkarni> :D
16:49:21 <adrian_otto> claytonc: is there a new blueprint for me to process?
16:49:22 <kraman> :) k
16:49:24 <claytonc> i have a todo to draft that as a sub-BP of the lang pack BP
16:49:50 <kraman> devkulkarni: perhaps after discussion with mordred we can merge that into git. lets see
16:49:53 <devkulkarni> kraman: but, yeah, it can be considered as a sub bp of the overall git workflow
16:49:55 <claytonc> it would be the Java/Python example image langpacks suitable for consumption by dev's get-lang-pack and specify-lang-pack
16:50:14 <devkulkarni> kraman: may make sense to do that.
16:50:34 <claytonc> but it would be strictly scoped to what is required for M1 and would serve as a foundation for later, post M1 specs that might deal with more complex langpacks
16:50:36 <adrian_otto> are there other new blueprints that we should consider for M1?
16:50:43 <kraman> claytonc: adrian_otto: need some guidance from lang-pack BP workgroup as to where they want the git-sources available for processing
16:51:08 <kraman> just FYI, perhaps it can be an item on next meeting agenda
16:51:14 <adrian_otto> kraman: okay, any suggestions?
16:51:17 <claytonc> kraman: we didn't get to that topic, the new spec would "own" that reqt and we can discuss it at next monday's meeting.  my initial thoughts are that it's an argument to a known "execution script"
16:52:12 <kraman> claytonc: sure. lets discussion next meeting. argument sounds fine. but it may need to be a (bind)-mounted into the VM or container
16:52:22 <claytonc> kraman: agree its both
16:52:23 <devkulkarni> adrian_otto: stating the obvious. anything that is required for end to end working example, and which has not been identified yet needs to be identified and scoped as part of current blue prints or new blue prints
16:52:35 <claytonc> the argument is to let the script know where it's bind mounted - since different OS' may not have the same path semantics
16:53:02 <adrian_otto> devananda: Thakns. I'm fishing for ones that meet that criteria that have been submitted as new that I should take notice of, and target accordingly
16:53:08 <adrian_otto> I did it again, darn it
16:53:16 <adrian_otto> ^^ devkulkarni
16:53:20 <devananda> :)
16:53:21 <devkulkarni> :)
16:53:22 <adrian_otto> sorry devananda
16:53:35 <paulmo> #link http://docs.openstack.org/security-guide/content/openstack_user_guide.html (OS Security Guide Link from previous discussion)
16:53:52 <adrian_otto> thanks paulmo
16:55:51 <devkulkarni> paulmo: is there any specific parts of the guide that developers should focus on first?
16:56:03 <adrian_otto> 5 mins remaiing
16:56:27 <paulmo> I think it is good to quickly review in general but I'll try to pull out what looks like Solum work vs operator/devops work for review by the group if that sounds good.
16:56:42 <devkulkarni> paulmo: thanks. that will be helpful.
16:57:11 <paulmo> Once we have that, we can start discussing security milestones.
16:57:27 <devkulkarni> paulmo: sounds good
16:58:06 <adrian_otto> ok, sounds like we are ready to wrap up
16:58:18 <adrian_otto> thanks everyone for attending!
16:58:23 <adrian_otto> #endmeeting