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