21:10:12 #startmeeting Solum Team Meeting 21:10:13 Meeting started Tue Aug 25 21:10:12 2015 UTC and is due to finish in 60 minutes. The chair is devkulkarni. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:10:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:10:18 The meeting name has been set to 'solum_team_meeting' 21:10:22 #topic Roll Call 21:10:27 Devdatta Kulkarni 21:10:30 o/ 21:10:31 murali allada 21:10:40 hi dimtruck, muralia 21:10:43 hi devkulkarni 21:10:45 hey 21:10:54 hi james_li_ 21:11:00 hi datsun180b 21:11:06 james li 21:11:15 #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-08-25_2100_UTC 21:11:21 today's agenda ^^ 21:11:47 nice to see you all 21:12:11 the agenda is mostly about reviews 21:12:36 #topic Announcements 21:12:49 I don't have any prepared announcements 21:13:02 anybody want to share something with the team? 21:13:29 i see lots of patches from you 21:13:40 muralia: yes 21:13:41 oh i'm here, just distracted 21:13:47 I am about to get to that 21:13:53 okay, since no announcements from anyone, moving on to next topic 21:14:02 #topic Review Action Items 21:14:29 I there were no action items from the last meeting 21:14:42 #topic Blueprint/Task Review and Discussion 21:14:56 ok, so this is the major topic for todays meeting 21:15:04 I have three items: 21:15:13 (devkulkarni/randallburt) Deployer plugins (Notes: Need one more +2) 21:15:20 I just saw james_li_ approve this 21:15:25 yes 21:15:32 thanks for that james_li_ 21:15:44 it has been there for a while 21:15:54 james_li_: yes, that is correct 21:16:11 now that this is merged, we can start implementing the plugin model for deployers 21:16:22 I am really looking forward to that 21:16:30 because, once that is in place 21:16:32 +1 21:16:46 it will be straightforward (hopefully) to integrate with magnum 21:16:53 +10000 :D 21:16:56 :) 21:17:14 I will be checking with randallburt on what are the next steps 21:17:24 and what needs to be done to start the implementation 21:17:45 should operator have an option of not running solum with magnum? 21:17:54 dimtruck, muralia: your knowledge with magnum should be useful when we get to implementing the integration 21:18:00 yup 21:18:04 james_li_: good question 21:18:23 I would assume that we would provide operator-level flags/overrides to choose what configuration solum uses 21:18:31 james_li: yes, operators can choose any backed to deploy apps 21:18:40 yup! 21:18:41 whether it is heat+magnum or just heat 21:19:42 more will emerge about pros/cons of this on that once we start implementing and experimenting I suppose 21:20:09 So next one in the review section is: 21:20:11 (devkulkarni) Request to review API patches. (Notes: These patches add the workflow resource and connect it to the Solum worker (and deployer)) 21:20:19 let me give some background on this.. 21:20:43 so as you all know we have accepted a spec to add 'app' and 'workflow' resource to solum 21:21:05 the four patches that I have listed in meeting agenda are implementing the workflow resource 21:21:20 before you look into the code 21:21:28 it might help to check out this spec: 21:21:50 #link https://review.openstack.org/#/c/215832/ 21:22:13 this outlines the approach that I have taken to connect the workflow resource to the main solum engine (specifically, worker and deployer) 21:22:30 the four code patches follow the approach outlined in the spec 21:22:40 I have not yet added tests 21:22:50 I will be doing that starting tomorrow 21:23:14 please take sometime, whenever you get a chance, to review these patches 21:23:34 imo, once these patches merge, we will have basic workflow resource implemented (end-to-end) 21:23:35 devkulkarni: i guess you did some tests manually 21:23:42 james_li_: yes — 21:23:49 I have tested manually 21:23:55 with CLI 21:23:57 ? 21:23:57 can show you if interested 21:24:03 yes, with CLI 21:24:07 ok 21:24:10 cool 21:24:26 I am hoping that we can get these patches merged soon 21:24:47 so that before the long weekend (next week), we could demo the end-to-end behavior with the new code 21:25:08 so looking for reviews. 21:25:15 datsun180b: as an fyi 21:25:29 you might see that I have added 'status' to the app model 21:25:51 it is a singular status rather than a dictionary as you have outlined in your spec 21:25:52 yeah, that part's tricky to convey 21:25:59 I have done that on purpose 21:26:11 older ideas, older models. i won't fuss about changes like that 21:26:12 my main goal for now is to get to feature parity with what we currently have 21:26:19 cool 21:26:30 just wanted to inform you about the diversion from the spec 21:26:39 rules are made to be broken 21:26:56 once this first iteration is complete, I will go back and add finer states etc. 21:27:06 that sounds entirely reasonable 21:27:11 awesome! 21:27:54 so the next item is the CLI patches: 21:28:01 (devkulkarni) Request to review CLI patches. (Notes: These patches add interactive input functionality to the new app commands.) 21:28:16 let me give some background on these set of patches 21:29:10 basically we want to achieve two things: 1) support the new app resource 2) add all the error checks, interactive inputs, etc. that we currently support to the new app paths 21:29:51 code that invokes the app and workflow rest APIs was already submitted as WIP by datsun180b 21:30:08 as long as feature parity is the goal i guess we can keep the interactive prompts 21:30:08 that has been the starting point for item 2 21:30:16 but ftr i don't like 'em 21:30:26 datsun180b: I would like to get to feature parity first 21:30:46 that way, if anyone wants to use it, the experience will be what we currently support 21:31:02 right, so i'm not going to fight any of those changes 21:31:17 datsun180b: thanks :) 21:31:33 so starting from your WIP patch 21:31:52 I am adding piece-by-piece support for other things 21:31:59 the patches should be easy to review 21:32:17 the code is almost similar to existing code 21:32:33 with simplifactions/changes to support the app-file model instead of the plan-file 21:32:58 btw 21:33:28 in both, API and CLI, I am planning to support git-triggers after the first iteration 21:33:45 aiming high 21:33:47 i.e., once the current workflow patches on the API side and the CLI patches are merged 21:34:11 datsun180b: actually, not aiming for git-trigger stuff at all for now 21:35:07 will start looking at porting the git-trigger related things (trusts in API, tokens in CLI) after the basic end-to-end workflow patches are completed 21:35:37 datsun180b: does sound like a good plan to you? 21:35:47 s/does/does that/ 21:36:10 seems like the most straightforward 21:36:15 datsun180b: cool 21:36:17 ya 21:36:33 so overall the next steps/plan in my mind is as follows: 21:36:48 1) complete basic end-to-end workflow (in progress) 21:37:01 2) complete basic CLI changes (in progress) 21:37:15 3) git-trigger on API 21:37:23 4) tokens/github support on CLI 21:37:31 5) pluggable deployers 21:37:39 6) magnum integration 21:37:52 6) non-destructive app update functionality 21:38:05 7) support for multi-repo applications 21:38:33 the last item may need overall changes 21:39:01 thoughts/comments? 21:39:29 oh btw, one more thing 21:39:40 sometime in between these 21:39:50 I would like to get james_li_'s bash-to-python patches merged 21:40:04 so james_li_, I will take a look at the config generator issue 21:40:13 but not right now 21:40:15 thanks 21:40:35 it will have to wait till I get at least till item 4 completed 21:40:57 cool 21:41:17 so moving on to the next topic 21:41:24 #topic Open Discussion 21:41:38 i've got a short one 21:41:43 datsun180b: floor is yours 21:41:51 devkulkarni in your workflow table you're adding a deleted_at field to workflow 21:41:59 who will delete workflows? 21:42:35 datsun180b: in our current model, app delete deletes all the assemblies 21:42:50 so it could be similar.. 21:42:55 however, 21:43:29 for preserving the history of workflow executions 21:43:55 we are not going to delete the record from the workflow table. hence you had the 'deleted' boolean flag 21:44:09 so then, the 'deleted_at' field is to record the time when this flag was set 21:44:22 i don't remember a deleted boolean 21:44:31 but in that case, carry on 21:44:32 it is there in the spec as well 21:44:52 perhaps it was soft deleted in my memory 21:44:56 datsun180b: I remember we discussing about soft delete 21:45:00 right 21:45:32 then i'm happy with your current procedure 21:45:40 datsun180b: cool 21:46:01 now there's a point where your code in these patches outweighs what i set out with in my WIPs 21:46:36 so how many grains until we have a pile here? 21:46:44 yes — there are some additions which build upon the WIP 21:47:14 datsun180b: I don't anticipate more patches (on the API side) 21:47:26 the four patches cover the basic end-to-end functionality 21:47:41 I will be adding tests as part of these patches themselves 21:47:48 still looking at the latest revisions but they look like they're all there 21:48:50 datsun180b: saw your comments on CLI patches 21:48:58 thanks for checking those out 21:49:36 i don't have any substantial quarrel with the CLI changes 21:49:45 thanks 21:50:10 I can move filter_lps back to solum.py 21:50:26 the reason I moved it to cli_utils was because it is required from both AppCommands and OldAppCommands 21:50:37 I understand that this is temporary 21:50:48 so here is what I can do 21:51:03 move it back to solum.py, but not make it part of any class 21:51:29 those sort of functions are getting numerous as is 21:52:02 true 21:52:45 we can revisit this once we are at feature parity with existing functionality 21:52:50 that's fine then 21:52:56 let me go double that +1 up 21:53:18 datsun180b: oh, cool 21:53:25 that is nice of you datsun180b :) 21:54:12 we are almost at the end of our meeting time 21:54:30 anything else for us to discuss today? 21:54:37 none from me 21:54:54 nothing further 21:55:05 want to convey sincere thanks to all for keeping looped in on solum reviews 21:55:24 james_li, datsun180b, dimtruck, muralia thanks for joining in today 21:55:30 see you all next week 21:55:35 thanks 21:55:41 #endmeeting