16:00:29 #startmeeting Solum Team Meeting 16:00:29 Meeting started Tue Dec 2 16:00:29 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:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:33 The meeting name has been set to 'solum_team_meeting' 16:00:46 #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-12-02_1600_UTC Our Agenda 16:00:51 #topic Roll Call 16:00:55 Adrian Otto 16:01:01 Navid Shaikh 16:01:01 Gil Pilz 16:01:03 Ed Cranford 16:01:10 Devdatta Kulkarni 16:01:36 hello everyone 16:01:42 howdy 16:02:19 o/ 16:02:41 we will begin in just a moment 16:03:11 if you do not type anything during roll call, that's okay, you can register your attendance at any time during the meeting by participating. 16:03:22 #topic Announcements 16:03:32 none prepared, any announcements from the team? 16:03:56 hello everyone.... i am looking to join the team 16:04:18 akshayc_: welcome! Would you like to share a bit about yourself? 16:04:32 hi akshayc_: welcome. and welcome to nshaikh as well 16:05:26 Hi, sorry missed roll call 16:05:27 i have used openstack and i really liked it. i am looking for ways to contribute. 16:05:36 welcome stannie 16:05:47 used personally, (not in production) 16:06:06 akshayc_: I have a blog for you to consider… 16:06:13 #link http://adrianotto.com/2014/08/how-to-be-awesome/ How to Be Awesome 16:06:19 o/ 16:06:30 dimtruck: just in time 16:06:34 sure.... also i was looking at the bug list.... 16:06:38 #topic Review Action Items 16:06:52 dimtruck to follow up on bugs 1359516 and investigate for any specific issues in replacing simple_server with mod_wsgi 16:06:53 Launchpad bug 1359516 in solum "Needs to handle http header 'X-Forwarded-Proto'" [Undecided,Confirmed] https://launchpad.net/bugs/1359516 16:07:24 dimtruck: any update on this? 16:07:30 ugh, sorry - thanksgiving killed me :( 16:07:36 can we push this forward one week 16:07:38 you are not alone 16:07:42 yes, I will carry it 16:07:45 you're in good company 16:07:50 #action dimtruck to follow up on bugs 1359516 and investigate for any specific issues in replacing simple_server with mod_wsgi 16:08:00 same :( 16:08:04 i suck 16:08:05 SHould I carry this one also: dimtruck to report back results of multi-node devstack with solum setup 16:08:24 yes please hahaha 16:08:26 #action dimtruck to report back results of multi-node devstack with solum setup 16:08:40 and like you, I was totally away from work... 16:08:44 #action adrian_otto to cut the final Juno release 16:08:55 I will complete that before we meet again 16:09:03 #topic Blueprint/Task Review 16:09:07 akshayc_: there are couple of bugs marked as low hanging fruit 16:09:20 this topic is to allow us to cover work tasks that require team collaboration 16:09:30 ok.... i wlll take a look.... 16:09:33 would anyone like to raise any? 16:09:39 any inparticular you are refering to? 16:09:52 nothing for now 16:09:57 don't remember any particular off the top of my head 16:10:01 oh yeah 16:10:15 so assembly logs is merged in solum but the logs command in client isn't. can i get a push on that? 16:10:25 datsun180b: sure 16:10:29 #link https://review.openstack.org/#/c/131292/ 16:10:45 thanks 16:11:20 ok, any others before open discussion? 16:11:52 #topic Open Discussion 16:12:00 I have one topic for this section 16:12:10 I have one topic as well 16:12:37 I had added it to the agenda: #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-12-02_1600_UTC 16:12:39 mine is pertaining to cli refinements and implications on the object model, database 16:12:59 adrian_otto: you go first 16:13:02 (devkulkarni) 16:13:02 Proposal: Change alternating meeting times to a single meeting time. Proposed time: 4.00pm CDT every Tuesday. 16:13:02 Use #openstack-meeting-alt if available at that time every Tuesday. If not, use #solum. 16:13:10 this will be fast, so we will cover this first 16:13:14 ok 16:13:25 stannie: I'd like your input on the proposed time 16:13:27 so I was wondering if we could go back to a single meeting time 16:14:17 do you have somewhere the proposed time in CET ? :) 16:14:30 one sec 16:14:51 I think it will be 11.00pm CET 16:14:54 #link http://www.worldtimebuddy.com/?pl=1&lid=8,100,6,12&h=8 Proposed Time 16:15:08 wait 16:15:13 one sec, I need to correct it 16:15:32 #link http://www.worldtimebuddy.com/?qm=1&lid=8,100,6,12&h=8&date=2014-12-2&sln=14-15 Proposed Time 16:15:40 perfect then 16:15:41 so that's 11pm for Paris. 16:15:43 thanks 16:15:57 no objections? 16:16:17 so if that's tied to UTC then it'll shift for us in the states in the spring 16:16:38 but that will be 1 hour forward, so should not affect Paris, right? 16:17:19 that will be fine 16:17:39 so that would be UTC 2200? 16:17:58 that's what wtb says 16:18:15 so on alternating weeks that wold conflict with the containers team meeting 16:18:20 right! 16:18:22 which I also chair 16:18:45 so either I'd need to miss it on alternating weeks, or see about rescheduling them 16:18:51 we can do one hour earlier if that works for you and also if we have the channel available 16:18:59 or you name a lieutenant for the off weeks? 16:19:02 another option would be to check on a slightly earlier time… perhaps 2100 UTC 16:19:23 I would say we consider 2100 UTC 16:19:37 if this channel is available we use it or we do it in solum on alternate weeks 16:19:43 datsun180b: I'm willing to do that 16:20:08 of course like dev says we'd need a different channel too, and i think that could be confusing if we used two channels 16:20:10 there are enough meeting channels to choose from 16:20:25 so let's just zero in on a weekly date/time, and I'll get us a free channel to use 16:20:38 sounds good. i have no problem with 2100Z 16:20:43 I am fine with 2100UTC 16:20:54 good, any objections to 2100Z? 16:21:20 ok, I'm proceeding to an agreed on this. Would you like to make next week the first? 16:21:33 yes. lets start from next week 16:21:34 yes 16:21:37 +1 16:21:41 since it's normally planned for 2200Z 16:21:47 ok, good 16:22:37 #agreed Future team meetings will be held at 2100 UTC in an availavle meeting channel to be announced by adrian_otto by email to the ML 16:23:05 #action adrian_otto to select IRC meeting channel for next team meeting(s) 16:23:30 #action adrian_otto to announce selected channel on ML, and update https://wiki.openstack.org/wiki/Meetings/Solum 16:23:36 thanks devkulkarni 16:23:49 so, we can advance to my open discussion topic 16:23:57 about cli refinement 16:24:07 thanks adrian_otto and everyone else for agreeing to change in meeting time 16:25:04 our first version of Solum the API was inspired by a desire to embrace open standards. We employed many of the concepts expressed in CAMP. gpilz contributed code for further CAMP compliance based on this API, and we now have a shared object model and database. 16:25:33 the terminology used in our current CLI mirrors the API closely 16:25:54 this results in a CLI that requires that the end user has a concept of the terminology used by CAMP 16:26:35 because CAMP has not been adopted by other systems used by today's software developers, we notice confusion when presenting the concepts of assemblies and plans for the first time 16:26:53 initially we expected the learning curve to be easily managed 16:27:34 that expectation has been met with challenge… the bottom line is that the concepts we are using to express the modeling of applications are not easily understood by our end users 16:27:45 to respond to that, we plan to refine the CLI further 16:28:10 working to adopt terminology that is already understood, and stepping away from the plan and assembly concepts 16:28:30 solum 16:28:41 or possible solum 16:28:48 aww away from plan you say 16:28:48 where the noun is usually "app" 16:29:14 yes, have I captured the intent properly? 16:29:38 you have, but i have a cli review choosing plan over app :c 16:30:01 no big deal, don't let me distract 16:30:02 don't worry about what's currently in play 16:30:09 about , other OpenStack services have - 16:30:23 heat stack-create, for example 16:30:29 vs. solum app create 16:30:40 yes, the "openstack" client (aka OSC) uses the noun verb ordering. This is a detail we can work out later. 16:31:02 sure.. just wanted to bring that up since we are anyways thinking of changing the CLI 16:31:39 now, I'd prefer if refinements to the API don't require a wholesale overhaul to the object model and database, and perhaps even the existing API 16:31:44 so adrian_otto, the problem definition is clear.. what is the proposal? 16:31:57 okay.. you are explaining that.. 16:31:59 I'm getting to that… sorry for being so verbose 16:32:20 it is tempting to chuck out the API, and make one that perfectly matches the "revised" CLI 16:32:21 no worries.. 16:32:42 my question is can we first try making a refined CLI with minimal adjustments the existing API and things below it 16:33:00 to prove that it helps us solve the "uuuh what???" problem that we perceive today with newcomers 16:33:33 makes sense 16:33:39 and if that's clearly the preference, to gradually work to true that up as tech debt. Those who know me well know that I am reluctant to propose this sort of tech debt. 16:33:49 yes.. if we want to change this we should do it piece at a time.. The "uuhh what" problem will still manifest if users are directly going to interact with the API 16:34:07 and I recognize that users of the API wills till be confused because there would be differences between that and the CLI 16:34:12 there's a lot of flexibility in what we can do with the CLI without having to make drastic changes to the api or the models 16:34:31 but I expect that most adopters of solum will make a decision on adoption primarily on the cli, not the API 16:34:34 users of the API can always look at the CLI code 16:35:18 devkulkarni: yes, exactly… and if we still have that problem, we should have this discussion again as it pertains to the API 16:35:43 slightly more reworking over time, but might allow us to try more using this approach 16:35:45 we should think about documenting the CLI code fairly well 16:35:51 +1 16:36:14 it should be really good at self documenting 16:36:47 running "solum" to get a list of all options, and "solum " to get help about 16:37:11 I am fine with this direction in general.. although it will be good to see the proposed nouns and verbs.. 16:37:24 I meant in the sense of serving as an example on how to use the API 16:37:44 devkulkarni: I know Roshan has a first take on this, so let's bring that out for discussion 16:37:52 possibly next week 16:37:58 okay, that will be good 16:38:10 we can also add to the API 16:38:25 so say we add an "app" resource that is a facade over plans and assemblies 16:38:39 that's another way to strike a balance between the interests 16:39:12 and for those who want to use the API to get more granular, the other resources are there to choose from 16:39:38 we have some measure of self-documentation https://gist.github.com/anonymous/a5de89a75a6ffe3291f8 16:39:46 arguably it could be much more rich 16:40:03 ignore my plan/app switcheroo 16:40:08 datsun180b: yes, that's it. We should see about how we can make that even better. 16:41:11 argparse's help functions and error handling are, uh, "fun" 16:41:24 :-) 16:41:34 it likes to exit(0) if you have the wrong number of args 16:41:59 ok, so let's keep this dialogue open. If it makes sense to give this a try, then perhaps we don't need to revisit it. 16:42:06 anyway glad to help make the cli better to use once we nail down what 'better' is 16:42:18 if we hit some fundamental roadblocks, then let's come back to this and see what choices we have to address it 16:42:35 sounds like a plan 16:42:49 datsun - clearly it needs to stop surfacing "assembly" - no one knows what that is 16:43:11 I want everyone to feel like we are sourcing input from all of you, and take any objections into consideration before commitment to sharp changes in direction 16:43:47 so if we miss this goal, please let me know so I can try to correct for it 16:43:51 changes to the DB schema are a trigger point for me 16:44:05 steps we had discussed earlier was to call plans plans to free up the word 'application', then build commands in terms of applications and melt the plan and assembly concepts out of the cli 16:44:37 datsun180b: sounds sensible 16:44:43 focused on changing the cli experience without having to change the api 16:44:53 we could also reconsider "template" rather than plan 16:44:59 sure 16:45:23 but to be clear, the CAMP API and Solum API are intentionally different, and will reman so 16:46:02 gpilz, I do expect that *some* change at the schema level may be needed, but I don't expect it to be major. 16:46:55 okay 16:46:58 are we happy with wrapping up this topic? 16:47:26 do we want to formalize further discussion of it? 16:47:32 sure. lets discuss this next week again when Roshan's draft will be available 16:47:53 datsun180b: let's touch base with Roshan, and I'll put it on next weeks agenda to revisit. 16:47:54 gotcha. i bet he's got some more fact-finding to do 16:48:17 we have some end user interviews to explore this from a research study perspective 16:48:24 I think we want to get some input from that angle too 16:49:24 ok, any more topics to touch on today? 16:49:46 well how about our new conscripts 16:49:52 how can we help you get started with solum? 16:50:37 hmm 16:50:44 we still have nova-docker issues in our devstack env 16:51:01 the one hosted in rackerlabs' github 16:51:02 nshaikh and akshayc_ 16:51:06 ^^ 16:51:19 so I guess newcomers will encounter this issue while trying to set their dev environment 16:51:52 do we have a fix for that ? 16:51:56 what issues? 16:52:08 i was looking at some bugs.... 16:52:22 cannot create regular file `/etc/nova/rootwrap.d/docker.filters': No such file or directory 16:52:45 strange OH i think i have an idea 16:52:51 that will affect dev.... is there a link to that bug? 16:52:53 oh this is due to the fact that 'docker-py' is not in global-requirements.txt 16:52:54 export NOVADOCKER_REPO=https://github.com/ed-/nova-docker.git 16:52:54 export NOVADOCKER_BRANCH=solum-pin 16:53:06 yeah i was about to go dig for that nova-docker pin i made 16:53:24 ^^^ there it is 16:53:31 thank you =) 16:53:40 will try it 16:53:43 we put a stake in nova-docker but then some of its upstream deps--oslo.concurrency--moved 16:54:04 so i added a quick commit to cover that difference 16:55:01 global-requirements issue will still be there 16:55:18 for that we need to go back to the commit on nova-docker which does not use docker-py 16:55:27 i thought we got docker-py by it being a dep of nova-docker? 16:56:55 #link https://github.com/rackerlabs/vagrant-solum-dev/issues/29 16:56:56 another option might be to make a (set of?) docker container(s) for running solum for dev, and those can be easily pinned to known good tags in the public docker registry 16:57:00 well let me know, any of you, if your vagrant environment starts screaming 16:57:14 we'll get to the bottom of those problems 16:57:36 that may actually start up much quicker than the vagrant setup we have now 17:00:27 see you all in #solum 17:00:38 ok 17:00:58 thanks for attending everyone 17:01:01 #endmeeting