16:00:12 #startmeeting Solum Team Meeting 16:00:13 Meeting started Tue Nov 12 16:00:12 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:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:16 The meeting name has been set to 'solum_team_meeting' 16:00:24 #topic Pre-Announcements 16:00:25 1) Roll Call will not need your company affiliation in #openstack-meeting-alt as that is not customary here. 16:00:25 You can simply respond with a hello of some sort. Responding at roll call is optional. 16:00:56 #topic Roll Call 16:01:05 Good morning! 16:01:22 Hey, Swapnil Kulkarni(coolsvap) here 16:01:36 Good morning! Georgy from Mirantis is here 16:01:40 Tom Blankenship, Rackspace 16:01:59 Hi folks, Uri Cohen, GigaSpaces 16:02:24 hi, Jessica Forrester 16:02:29 Clayton Coleman 16:02:47 Paul Czarkowski, Rackspace 16:02:58 Murali Allada, Rackspace 16:03:52 alex heneveld, cloudsoft 16:04:36 would you all like to have an informal ODS retrospective during our open discussion today? 16:05:01 }1 16:05:04 +1 16:05:04 Yes. 16:05:18 +1 16:05:23 Dan McPherson, Red Hat 16:05:25 +1 16:05:32 Sandeep Puri, Cisco 16:05:38 +1 16:05:41 Subbu Allamaraju, eBay 16:05:46 okay, I will raise that for discussion right before open discussion 16:05:59 Devdatta Kulkarni, Rackspace 16:06:45 okay, let's proceed. 16:07:03 anyone else may chime in at any time. 16:07:06 #topic Review action items from prior meeting 16:07:06 * adrian_otto adrian_otto to create a breakout session index on the wiki (adrian_otto, 16:58:01) 16:07:06 Status: completed: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings 16:07:29 that was the only action item 16:07:31 #topic Announcements 16:07:44 1) Mirantis is joining the Solum team. Please welcome them. 16:08:08 welcome! 16:08:18 Welcome folks! 16:08:24 we have gokrokve_ here with us this morning 16:08:39 Welcome, even though i am also new! 16:08:45 Hello! 16:08:45 Thank you! 16:08:49 rajdeep: welcome! 16:08:56 We plan to have more folks from Mirantis here. 16:09:48 great! 16:09:49 adrian_otto: small typo on the wiki - it is referring to #solum channel 16:10:00 Was that intentional> 16:10:02 ? 16:10:02 oh, my 16:10:09 which page is that appearing on? 16:10:15 https://wiki.openstack.org/wiki/Solum/BreakoutMeetings 16:10:31 actually, that's right, those will be in #solum 16:10:46 Hello 16:10:57 Hello ) 16:11:03 k 16:11:04 because the #openstack-meeting-alt channel is used for regularly scheduled meetings 16:11:07 hello :) 16:11:23 and I did not want to interfere with any others 16:11:36 Subbu_: will taht be okay, do you think? 16:11:56 makes sense. less conflicts 16:12:12 okay, so here is our next announcement: 16:12:17 2) Solum API Deep Dive schedules for this week: 16:12:17 PART I: Wednesday 2013-11-13 1:00 PM US/Pacific (2100 UTC) 16:12:17 #link http://www.worldtimebuddy.com/?qm=1&lid=8,0,4726206&h=8&date=2013-11-13&sln=13-14 16:12:17 PART II: Friday 2013-11-15 1:00 PM US/Pacific (2100 UTC) 16:12:17 #link http://www.worldtimebuddy.com/?qm=1&lid=8,0,4726206&h=8&date=2013-11-15&sln=13-14 16:13:02 looks very asia unfriendly time 16:13:04 :( 16:13:05 as discussed above, these will be in #solum and are intended for those who are interested in this topic to spend more focused time on it 16:13:24 the timeslot was selected from a croudsourced poll. 16:13:33 adrian_otto: is the plan for the deep dive to do part of it on IRC so folks can participate that aren't in the office? 16:13:34 sorry for those of you on the other side of the globe. 16:13:46 ok np 16:14:06 fungi: they are IRC meetings. What did you mean? 16:14:15 adrian_otto: didn't realize that 16:14:20 It is midnight for most of Mirantis folks 16:14:24 oh, yes, you can participate by IRC. 16:14:54 stanlagun: sorry about that. We secured the timeslots before we knew you would be joining us. 16:15:19 we used a tool called Doodle, which we will use again when we select future meeting times. 16:15:41 so if you see a link to Doodle anywhere in the ML, be sure to participate in that so we can accommodate your preferences. 16:15:52 next announcement... 16:16:12 3) My deepest apologies for the confusion on the meeting time. My calendar emitted a rouge meeting invite. 16:16:12 PLEASE *delete* all appearances of "Solum Team Meeting" or "Solum Weekly Meeting" from you calendars. I will find a way to start fresh. 16:16:55 those of us in attendance already got the right time. 16:17:07 so my apologies to those of you reading this from transcripts. 16:17:27 okay, next we will move into blueprints 16:17:37 I have a few that were carried over from a prior agenda: 16:18:06 #link https://wiki.openstack.org/wiki/Meetings/Solum 16:18:22 #topic Git Deploy Blueprint 16:18:30 #link https://blueprints.launchpad.net/solum/+spec/git-integration 16:18:43 Present child blueprints and identify any ready for approval. 16:18:55 (do we actually have anything new on this to discuss) 16:18:57 ? 16:19:15 one question : what if developer is not using git as a source control 16:19:16 we also have... 16:19:25 rajdeep: good question 16:19:34 they will be able to bypass that 16:19:53 they will have a few options, including using the REST API directly 16:19:58 using a CLI tool 16:20:06 using an IDE plugin, or another UI 16:20:12 adrian_otto: Is this blueprint taken to mailing list? 16:20:22 hg? TFS? 16:20:27 there has also been discussion about pluggable source 16:20:31 Git is the initial focus 16:20:32 yes, we can discuss this on ML. 16:20:40 Will the git commit pass a gerrit review before? 16:20:46 did y'all get the chance to discuss this at all in HK? 16:20:53 but the desire would be to abstract that detail to a source provider 16:21:00 gokrokve_: we have not discussed that yet, but we might use Gerrit in Solum 16:21:11 Is it supposed that there will be some specific development process? 16:21:11 Gerrit would host the git repo in that case 16:21:15 it would be a good idea to implement a gate, that could be jenkins or gerrit or whatever 16:21:17 i guess wrapper is a better approach and pluggin git, svn , TFS 16:21:35 alexheneveld not everyone was present in HK. A lot of the design discussion will also take place at F2F 16:21:42 funzo: that's a good point - there are probably two source flows: a) pushes to a repo, b) flows from a gate 16:21:58 any review tool (like gerrit) probably should not have tight coupling - more likely an optional coupling 16:22:04 k thx adrian_otto - as some of you know my 2p is that this will be easier if we split it into smaller parts 16:22:04 claytonc: +1 16:22:06 sapuri: absolutely 16:22:10 we have not sorted out how best to support the gating use case 16:22:25 code repo and build on one side ... deploy and run on the other 16:22:26 but we will certainly allow a deployment artifact to bypass the build and go straight to deployment 16:22:31 sapuri +1, many enterprise developers find gerrit cumbersone 16:22:37 so if you want to run your own Jenkins, you can do that 16:23:27 if we keep the seperation clean and just have git invoke REST API when it is ready to push out code. might make it more flexible for other source controls as well 16:23:29 we have room for this on the Design Workshop agenda, so we can revisit it then too 16:23:39 What is gonna be in that git for short-term plans? Python projects? Or do you plan on building C++ apps etc? 16:23:54 kraman: +1 16:24:02 stanlagun: that is intended to be generic 16:24:14 see the language packs discussion in the wiki 16:24:26 kraman: +1 16:24:27 kraman: +1 16:24:37 claytonc: +1 16:25:15 I should have mentioned the Design Workshop in the announcements section, sorry. Here is the registration link if you plan to attend in person in San Francisco on Nov 19+20: 16:25:19 #link https://www.eventbrite.com/event/9130831563 16:26:28 I will be with you all in spirit. 16:26:56 we will be in #solum too 16:27:02 thx for the link 16:27:09 and we are discussing how we might also use Google Hangout for some of it 16:27:22 adrian_otto : +1 :) 16:27:47 my understanding is that there are 3 meeting rooms so we can have concurrent meetings 16:27:49 for #solum & hangout, I will be on lookout for its announcement 16:27:52 great 16:28:02 +1 for hangout 16:28:25 +1 for hangout too 16:28:45 I am trying to understand a use case for DU Count > 1 16:28:52 ok, we have a few more blueprints to touch on 16:29:00 noorul: php and python parts of an app 16:29:02 that's one 16:29:05 Regarding Jenkins, do you see it inside solum to make actual build or it should be outside? 16:29:07 there was a long ML discussion on that a while back 16:29:17 #topic Shell Access Blueprint 16:29:23 noorul: about whether it was a good idea 16:29:26 #link https://blueprints.launchpad.net/solum/+spec/shell-access-to-du 16:29:50 so on ssh key distribution specifically, had a long discussion with adam young at design summit 16:30:15 one concrete point of statement from keystone was that they don't plan on being a key distribution / change management system (even though they might implement ceilometer notifications for credential added / removed) 16:30:35 so an integrator wishing to implement ssh access and distribute keys would need to build something on top of keystone to do that 16:30:42 Cloud Keep (barbican) may be a good fir for that 16:30:53 claytonc : +1 16:30:55 s/fir/fit/ 16:31:23 adrian_otto: the one integration point that might complicate it is the many to many relationship of keys (user a has 10 keys, user b has 10 keys, they can overlap occassionally for machine system keys) 16:31:37 would be good to talk about barbican on ML or in a breakout related to this topic 16:31:38 #link https://github.com/cloudkeep 16:31:48 adrian_otto: yeah, I heard folks talking about barbican being the key distribution of choice 16:32:08 claytonc: +1 - on many to many 16:32:12 in a nutshell, it's a central place where you can store secrets 16:32:15 Do you plan to support Windows as well? 16:32:37 Same here. barbican was suggested as best way to distribute keys to applications as well. But that will depend on the container APIs to some extent 16:32:37 stanlagun: as guests? 16:32:48 yep 16:33:01 noorul: maybe we should write up examples of multi DU on ML and try to counter example each one (about why it's a bad idea or not) 16:33:01 ssh seems like a special case of the need to expose a management interface for DU's in some cases 16:33:04 stanlagun: in theory if using instances, that would be possible 16:33:12 stanlagun: it's not explicitly mentioned as a goal, but language agnostic is. I see no reason why Windows could not be supported if there were a language pack for it. 16:33:30 alexheneveld: good point - there are operations above and beyond ssh 16:33:48 (and also for services) -- many will have a management dashboard for which barbican (or similar) would make sense for credential mgmt 16:33:49 however SSH typically has specific key authorization needs that you can avoid via other management points - i think the key aspect is what makes it special 16:34:11 interesting discussion about windows - it further lowers the common denominator :) 16:34:12 alexheneveld: on openshift its used a lot during development and some during production to be able to log in and see what the processes are actually doing. cant run strace etc without shell access 16:34:19 so do we have a desire to break this BP up into more child BP's that we can assign as work items? 16:34:36 This depends on overall architecture. Window might be very different. No SSH connectivity, np GNU toolstack etc 16:34:42 +1 claytonc - nice if user can supply a public key / credential where that is possible 16:34:48 What about HTTPS\CLI option? It is mentioned in BP. 16:34:57 stanlagun: definitely more complicated issues to think about re containers 16:35:31 i'd like to make sure what we build doesn't rule windows out -- but do any of us want to endure that pain now :) 16:35:59 * funzo slowly takes one baby step back. 16:36:02 Well you can never be sure until you try one 16:36:19 my guidance on this is to keep windows in mind, and focus initially on the language types that will run on *nix 16:36:20 alexheneveld: stanlagun a good way to think about it is that we should allow the mechanism by which you deploy to be plugged enough so that you can pass the appropriate info to start a windows instance and configure it 16:36:32 (via heat) 16:36:44 what adrian said 16:37:01 +1 16:37:13 Windows is where all of your futures would be most interesting because there are not many solutions for that OS. If you can handle windows Linux wouldn't going to be a problem either 16:37:13 and we should consider windows compat as a key criteria when evaluating options for the design 16:37:15 kraman: absolutely we must be able to set up ssh access for many DU's. (though there could be some where it isn't ... e.g. if it's running in a multi-tenant JVM or OSGi framework...) 16:37:44 not necessarily implementing both tracks. 16:37:46 alexheneveld: kraman possibly DU's have a set of capabilities that are intrinsic to what they are (containers, multitenant jvm, windows) 16:37:49 i'm just saying we want to be able to expose *other* types of management endpoints which will also require credential mgmt 16:38:08 alexheneveld: indeed 16:38:30 ok, let's proceed to our next BP 16:38:39 #topic WSGI Framework Discussion 16:38:39 Pecan+WSME vs. Falcon 16:38:47 how user will connect to the different instances via ssh? only one session for one host? 16:38:47 #link https://review.openstack.org/#q,topic:bp/rest-api-base,n,z 16:38:52 alexheneveld yes, ssh or just shell access seup should be optional and up to cloud provider 16:39:30 tnurlygayanov: that needs to be worked out still 16:39:41 yep - a bunch of different capabilities of various types of {DU's, lang packs, services, kumquats} 16:40:25 thats why I mentioned Windows in the first place as there is no SSH there 16:40:27 ok, I offered this guidance last week: http://lists.openstack.org/pipermail/openstack-dev/2013-November/018430.html 16:40:55 adrian_otto: Have we decided to go with Pecan+WSME? What were some of the discussions you had with others at the summit in this regard? 16:41:00 supporting multiple OS will complicate things a lot 16:41:02 I am seeking input on Falcon, as I have suggested we proceed with Pecan+WSME 16:41:05 adrian_otto: so are we just going with falcon if that's what's in the patch 16:41:09 not sure how man paas can do that today 16:41:11 ah 16:41:26 look at the review topic linked above 16:41:39 we have a patch for Falcon, and another for Pecan+WSME 16:42:02 at: https://review.openstack.org/#q,topic:bp/rest-api-base,n,z 16:42:17 i see 16:43:12 I'd like to hear more about the discussions that were had with the community around Falcon vs Pecan+wsme at the summit 16:43:56 adrian_otto: no opinion on either, i like your suggestion in the mailing list that, we should pick what other openstack projects are using, as a starting point 16:44:21 muralia: most projects are switching or are planning to switch to Pecan+WSME 16:44:30 I discussed it at length with Kurt Griffiths, 16:44:41 who is a key contributor to Falcon 16:45:15 the documentation angle and the separation of API abstraction slightly from the underlying domain model abstraction were the factors that convinced me that pecan+wsme was the better choice for a general, control-plane API. 16:45:29 and a number of PTL's on OpenStack projects 16:45:53 claytonc: +1 16:45:57 Jay Pipes has good criticisms of Webob and WSME 16:46:18 Pecan (0.3.2) 7,111 req/sec Falcon (0.1.7) with Cython (0.19.1) - 52,858 req/sec according to off site 16:46:25 I also sourced input from Clayton, and others from RH 16:47:14 stanlagun: I see that performance difference as acceptable, from the perspective of a large scale cloud operator. 16:47:31 control plane API's just don't see request rates that high 16:47:44 everyone seems in violent agreement, but for the order of magnitude difference wrt pecan 16:47:57 and if they are, that means you have a service with a ton of usage, and can use horizontal scale out to address it 16:47:57 as a practical example, in openshift we see control plane traffic that is roughly 1-2 req/sec per ten thousand active applications 16:48:28 however +1 adrian_otto claytonc -- for the requests this will be handling raw throughput is less important than maintainability 16:48:31 scale that up to ten million active active applications you're talking 1k req/s which is achievable using tens of python servers 16:48:37 claytonc: we see similar use patterns in our existing systems that offer Web UI capability 16:48:43 I personally find falcon to be easier to use and less bulky. But I do buy into the separation of domain and api models. Performance is not really the issue. 16:49:23 the higher throughput might be needed for the language pack, but falcon could still be used in language pack 16:49:50 adrian_otto: Webob used the be a problem but no longer an issue based on discussions during summit. 16:50:02 agree. I also would like Pecan more. The only concern with performance here is it is good to have common approach for all projects and for some of them performance can be an issue 16:50:05 in the absence of any new key drawback, I wold like to mark a decision in the direction of Pecan+WSME, and revisit it as needed. If it turns out that we have a real performance concern at some point, we can evaluate a tear out of Pecan+WSME, or other optimization options. 16:50:10 alexheneveld: the language packs can use any api or language they wish. doesnt have to be the same as solum 16:50:43 As long as the control plane is stateless, and gets zero traffic from running hosts, we can handle. We had issues some OpenStack components like neutro which get traffic from data plane. 16:50:44 kraman: +1 16:50:50 adrian_otto: +1 ... enough talk 16:50:54 any objections prior to advancing the topic? 16:50:59 adrian, kamran : +1 16:51:03 +1 16:51:06 +1 16:51:10 +1 16:51:10 +1 16:51:14 +1 16:51:19 Subbu_: would recommend that data plane traffic into solum be a separate scalable component anyway 16:51:19 +1 16:51:19 doit 16:51:32 #agreed we will use Pecan+WSME as the WSGI Framework for solum, to be revisited as-needed. 16:51:39 that's a good addendum to adrian's comment - pecan is for control plane traffic 16:52:00 claytonc: agreed 100% 16:52:16 #topic ODS Retrospective 16:52:32 The HKG summit was full of a lot of energy 16:53:20 Missed the summit - was there Solum discussion/session? 16:53:23 about 99% of it toward Solum was positive. I expected more controversy. It seems that random bloggers have more criticisms than the core of the OpenStack community. 16:53:34 oh, in summary of events: 16:53:44 I had a Lightning Talk on day 1 16:53:53 Unconference sessions on Day 2 and 3 16:54:03 Nice 16:54:04 a Panel on Day 1 where Solum came up a bit 16:54:25 and an Panel on Day 4 16:54:36 the best piece of criticism I heard was about whether Solum inside OpenStack drives people out of openstack or brings them in (relating this back to heat discussions that occurred previously). My argument there was that we are growing the space of potential people who can be involved in openstack (language authors, development tool frameworks, CI/CD, containers) more than we are hurting 16:54:39 We also had a design session on Container support on day 4 16:54:42 http://www.forbes.com/sites/benkepes/2013/11/04/breaking-sorry-rackspace-et-al-ubuntu-to-offer-openstack-hosted-cloudfoundry-based-paas/ 16:54:42 it was mentioned in the RedHat keynote 16:54:57 I saw that the other day 16:55:12 I see all the Cloud Foundry buzz as irrelevant 16:55:47 i do not think the bloggers are "random" ... everyone has their agenda #ignore 16:55:51 the question really is about will Solum have the support it needs from community contributors to make it a valuable addition to the OpenStack ecosystem 16:56:13 and that's clearly a yes. 16:56:34 there was one question that Clint Byrum raised in the Friday panel 16:56:38 running code 16:56:40 adrian_otto: +1 16:56:42 adrian_otto: that's what I was referring to above 16:56:50 adrian: I agree, have seen a lot of community interest in Solum in ODS 16:56:55 about Heat being a disruptive force, and that Solum may also be disruptive 16:57:02 i had one question on messaging layer 16:57:16 upon reflection, I did think of a better response 16:57:31 that disruptive forces generally result in an overall improvement 16:57:39 but can cause short term setbacks 16:58:12 the long term gain is a certainty in my mind. Developers will become more productive using cloud technology when our vision is achieved. 16:58:23 i'd also make the point that up until now openstack has focused mostly on administration and resource allocation - but IT is larger than it. I see openstack as helping IT organizations deliver value to their companies, and application lifecycle is a huge component of that 16:58:23 and that's a good thing. 16:58:33 on that note adrian_otto open source is a huge disruptor ... typically decimates a market when there is an open source solution 16:58:39 but is ultimately a good thing (imho :) ) 16:58:39 I need to hit on open discussion too 16:58:44 as we are running low on time 16:58:50 #topic Open Discussion 16:59:15 adrian_otto: Is this still worked on http://lists.solum.io/pipermail/solum/2013-October/000130.html ? 16:59:26 rajdeep: messaging? 16:59:33 (or take to ML) 16:59:44 ok i will ask there 16:59:52 noorul: I will need an update from Roshan on that one. 17:00:07 I think that task is still pending 17:00:15 If anyone is interested in looking at what it will take to better integrate containers into Nova (or perhaps create a new service), please add your email to https://etherpad.openstack.org/p/docker-nova-hkg around line 70 17:00:17 #endmeeting