21:01:03 #startmeeting Solum Team Meeting 21:01:03 Meeting started Tue Apr 21 21:01:03 2015 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:06 The meeting name has been set to 'solum_team_meeting' 21:01:12 #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-04-21_2100_UTC Our Agenda 21:01:20 #topic Roll Call 21:01:21 ed cranford 21:01:22 Adrian Otto 21:01:25 murali allada 21:01:28 Melissa Kam 21:01:32 first 21:01:36 devdatta kulkarni 21:01:41 dimitry ushakov 21:01:44 gilbert pilz 21:02:00 james li 21:02:08 Hello datsun180b, muralia, mkam, devkulkarni, dimtruck, gpilz, and james_li 21:02:15 hey hey 21:02:19 yes, datsun180b you are definitely first! 21:02:38 n 21:02:39 I was just saying to hub_cap how much I like your sense of humor 21:03:30 too bad you didn't tell him how much you like my commits or specs 21:04:50 well, in fact I did (no lie)… well I did not mention specs, but I do admit you are good at that. 21:04:59 ok, let's begin 21:05:04 #topic Announcements 21:05:42 1) Openstack Summit is coming in May. Would you like to still hold a team meeting on Tuesday May 19th? 21:05:53 if so, we'll want to appoint a chair for that 21:06:05 as I'm about to update the calendar for the next several weeks 21:06:37 we could.. what are other projects doing? 21:06:41 don't see the point 21:06:43 we could just cancel the meeting that week 21:06:53 most teams skip that week 21:06:58 yeah we can skip one if folks are going to be convening 21:06:58 at least for IRC proceedings 21:06:59 thought so.. 21:07:03 lets skip it then 21:07:05 we've always got #solum anyway 21:07:10 yes, lets skip it 21:07:14 #agreed no meeting on May 19 21:07:32 any announcements form team members? 21:08:04 The vagrant setup is back working again 21:08:21 I have a patch (not merged yet) 21:08:28 woohoo. you mean deployments. 21:08:37 which will allow testing of custom language packs + deployment on devstack 21:08:39 * adrian_otto high fives devkulkarni 21:08:48 it still uses the nova-docker driver 21:08:53 like before 21:09:01 and glance for storing the built DUs. 21:09:11 I will remove -1 workflow from it soon 21:09:26 hopefully in the summit folks will be able to try solum 21:09:52 that is all as far as announcement on this topic from me 21:10:03 thanks adrian_otto 21:10:07 excellent news, thanks devkulkarni 21:10:35 ok, we'll wrap up announcements and advance topics unless there are more… 21:10:53 #topic Tagging or next release 21:10:57 are we ready for this? 21:11:05 I did not get a heads-up on this one yet 21:11:08 soon! 21:11:17 not yet adrian, we're still make a few changes to the CLI 21:11:19 ok, just let me know 21:11:24 mkam is constructing a compatibility matrix 21:11:51 we'll insert that into the reactor and finally pierce the veil between this world and the Phantom Zone 21:11:59 #topic Review Action Items 21:12:05 and, also, verify that all our use cases are supported by the cli changes 21:12:14 * adrian_otto adrian_otto to spring clean our blueprints 21:12:14 * adrian_otto adrian_otto to spring clean our bug list 21:12:23 status of both of these is pending, sorry. 21:12:33 I will carry them forward and work on them more. 21:12:42 #action drian_otto to spring clean our blueprints 21:12:47 #undo 21:12:48 Removing item from minutes: 21:12:53 #action adrian_otto to spring clean our blueprints 21:13:01 #action adrian_otto to spring clean our bug list 21:13:13 #topic BP/Task Review 21:13:24 any work items that could use team discussion today? 21:13:28 someone needs to tell the bot to define __repr__ for ircmeeting.items.Action 21:14:21 adrian_otto: there was one item.. 21:14:33 devkulkarni: cool 21:15:01 so currently we support private git repositories (clone, triggering builds, and posting back status urls). 21:15:37 do you (or others) know if folks tend to use https/git protocol for interacting with private repositories? 21:16:39 the reason I ask is — our current implementation is based on the assumption that private git repositories will be used with the git protocol 21:17:15 yes, people certainly do 21:17:45 okay.. so is it alright for us to make this assumption (at least for now?) 21:18:00 there are really two ways to do it… with a git client, or directly on a web app like Github using on-line editors and such… which almost nobody does. 21:18:10 what other ways might they use? 21:18:11 i want to change over to prefer oauth while still supporting deploy keys if they're available, i'm not a fan of the mandatory keypair generation we do in plan-create 21:19:00 that would be an improvement, I think 21:19:49 datsun180b: are you saying we should only support oauth + https 21:20:01 or both (oauth and deploy_keys)? 21:20:34 what's the drawback of allowing both? 21:20:54 implementation complexity? 21:20:54 good question adrian_otto 21:20:55 i said prefer 21:21:01 right.. code complexity 21:21:46 but not supporting one or the either is problematic 21:21:48 also 21:21:56 and complexity is my reason, too. git clone https://(oauth ? "oauth:@" : )github.com/blargle 21:22:03 as then we are going to loose out on some of the usecases 21:22:13 versus ssh-agent-wrapped cloning 21:22:42 which yo do with a deploy key 21:22:48 datsun180b: agreed about this point.. but how do you support the use-case of having unittest scripts 21:23:06 that contain embedded in them git@ based urls? 21:23:27 education! documentation! threat of severe beatings! 21:23:57 and of course, still supporting both methods 21:24:14 devkulkarni, arnt we planning on addressing private https git urls by translating them to git@ 21:24:36 im adding code to the CLI to do that right now 21:24:38 we don't need to do that 21:24:40 my preference is to attempt to support both 21:24:57 and if the implementation or support/maintenance of that code is judged to be burdensome, then revisit it 21:25:07 I'd hate to prematurely optimize it 21:25:16 thoughts? 21:25:48 +1 21:26:11 my fan is desperately trying to cool my computer while i figure out the middle path 21:26:12 I am okay with this as well.. for the reason that we don't want to regress on some of the usecases that we already support by removing support for deploy_keys 21:27:26 so +1 21:27:30 neat 21:27:48 ok, let's come back to it if this turns out to be a PITA 21:27:56 sounds good 21:28:01 +1 21:28:19 ok, any other work items to discuss? 21:28:53 #topic Open Discussion 21:28:53 just want to bring attention to the spec on app resource 21:29:02 aah, ok 21:29:05 gpilz: you might want to check it out 21:29:13 will do 21:29:17 thanks gpilz 21:29:43 #link https://review.openstack.org/173564 App resource 21:30:06 i've got to address some comments yet, so there'll be a new version of that soon enough 21:30:47 i think the registration history may be a reach, if the actions instead store their what-was-cloned-or-deployed data 21:31:02 so i can flatten app a bit and remove a whole table and confusing resource 21:31:41 +1 datsun180b 21:32:42 We need to think about replacing existing resources. maybe we can reuse some of them instead of creating new resources. 21:33:23 but my fiddle and my matches :c 21:34:15 muralia: fair suggestion. Which approach might get us to a faster result? 21:34:36 maybe continue using assembly instead of action. 21:35:23 to be called action and back ended by assembly? 21:35:46 that would probably be confusing to maintain, right? 21:36:12 no, just use the same name, just change the schema. we dont expose assembly resource to the user anyway. its just an internal resource 21:36:15 i think the changes i'm proposing are dramatic enough to warrant a different resource and name from the way they're handled 21:36:31 we do actually expose assembly to users though, and i want to put a stop to that 21:37:02 there is no harm in exposing that in the CAMP 1.1 API code 21:37:32 datsun180, wont we expose 'app' to the user? not assembly 21:37:47 right, and an app isn't just an assembly 21:38:01 or a set of them for that matter 21:38:35 ok. I'll add comments to the doc and we can discuss there. i need to re-read it as well 21:38:41 cool 21:42:13 should we wrap up a bit early today? 21:42:18 yup 21:42:20 sounds good 21:42:23 cool 21:42:42 our next meeting is Tuesday 2015-04-28 at 2100 UTC in #openstack-meeting-alt 21:42:46 see you all then! 21:42:58 all right 21:43:02 #endmeeting