17:00:21 <devkulkarni> #startmeeting Solum Team Meeting
17:00:21 <openstack> Meeting started Tue Dec  8 17:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is devkulkarni. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:25 <openstack> The meeting name has been set to 'solum_team_meeting'
17:00:32 <devkulkarni> #topic Roll Call
17:00:36 <devkulkarni> Devdatta Kulkarni
17:00:37 <ashishjain> Ashish Jain
17:00:53 <devkulkarni> hi ashish..
17:00:59 <devkulkarni> I see datsun180b around too
17:01:04 <datsun180b> I'm here all right
17:01:06 <ashishjain> Hi dev
17:01:11 <devkulkarni> vijendar is going to bit late
17:01:14 <devkulkarni> hi datsun180b
17:01:20 <datsun180b> just looking at the agenda and the reviews needing approval
17:01:36 <devkulkarni> datsun180b: cool..
17:01:47 <devkulkarni> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-12-08_1700_UTC
17:01:50 <devkulkarni> that is our agenda
17:02:11 <devkulkarni> I think I saw james_li around too
17:02:12 <ashishjain> the patch "https://review.openstack.org/#/c/250020/" looks fine to me I have used it and it works
17:02:21 <ashishjain> have provided my comments as well on it.
17:02:22 <james_li> james li
17:02:40 <devkulkarni> ashishjain: thanks for verifying
17:02:44 <devkulkarni> hi james_li
17:02:52 <james_li> hi devkulkarni
17:03:08 <devkulkarni> looks like you also are on top of the patches needing one more +2
17:03:10 <devkulkarni> awesome
17:03:23 <james_li> just approved a doc change
17:03:58 <devkulkarni> james_li: nice.. yeah we got couple of folks submitting the doc change patches
17:04:30 <james_li> yeah
17:04:35 <devkulkarni> #topic Announcements
17:04:43 <devkulkarni> I don't have any prepared announcements
17:05:15 <devkulkarni> Any of you have any announcements? .. will wait for 30 seconds before proceeding
17:05:38 <datsun180b> Not from me
17:06:19 <devkulkarni> alright.. moving on to next topic
17:06:36 <devkulkarni> #topic Review Action Item
17:06:47 <devkulkarni> I had one action item which I just remembered
17:06:54 <ashishjain> ya readthedocs
17:06:59 <ashishjain> related
17:07:06 <devkulkarni> yes, that one and one more
17:07:24 <devkulkarni> I removed the readthedocs action item as I have been just carrying it forward for quite a while
17:07:25 <ashishjain> hmmm was it a question on tag I asked sometime back?
17:08:15 <devkulkarni> ashishjain: could you refresh my memory on it.. the action item was to send a note to openstack-dev mailing list that our meeting on December 29th is cancelled
17:08:22 <ashishjain> diverse-affiliation
17:08:29 <devkulkarni> ashishjain: oh that's right
17:08:35 <ashishjain> :)
17:08:45 <devkulkarni> let me take both of those action items again
17:09:31 <devkulkarni> #action devkulkarni to figure out details about diverse-affiliation tag associated with solum.
17:09:48 <devkulkarni> #action devkulkarni to send a note to openstack-dev mailing list that our meeting on December 29th is cancelled
17:10:36 <devkulkarni> #topic Blueprint/Bug Review and Discussion
17:11:00 <devkulkarni> We have four top-level items to discuss today
17:11:07 <devkulkarni> 1) Patch(es) needing one more +2
17:11:15 <james_li> done!
17:11:20 <devkulkarni> probably all the patches are done
17:11:23 <datsun180b> they are
17:11:24 <devkulkarni> james_li: awesome!!
17:12:15 <devkulkarni> james_li, datsun180b: cool
17:12:24 <james_li> devkulkarni: sure
17:12:27 <devkulkarni> all the new contributors are going to be happy :)
17:12:35 <ashishjain> james_li: just saw your comment on https://review.openstack.org/#/c/254344/
17:12:50 <devkulkarni> 2) Patch(es) needing discussion
17:12:55 <devkulkarni> https://review.openstack.org/#/c/254344/
17:13:12 <devkulkarni> this is the same patch as listed by ashishjain above
17:13:32 <ashishjain> Why I have removed this code is as the assembly is already being removed this code snippet "objects.registry.Workflow.destroy(app_id)"
17:14:07 <ashishjain> and the idea was to first remove all the stacks and than go about cleaning apps, assemblies, plans, workflows
17:14:18 <devkulkarni> ashishjain: you mean in line 313?
17:14:46 <james_li> but is destroy_assembly() is called anywhere else?
17:15:09 <ashishjain> Talking about 213 & 236 now Yes same reason is applicable to line number 313 as well
17:15:11 <devkulkarni> james_li: in line 310
17:15:46 <ashishjain> james_li : in line 310 in the new code
17:16:33 <james_li> I know. i meant you changed destroy_assembly(), but is it called anywhere other than destroy_app()?
17:16:57 <devkulkarni> good point james_li
17:17:35 <ashishjain> james_li: that is a valid point
17:18:49 <devkulkarni> searching through the code, it looks like destroy_assembly is getting called only from destroy_app
17:19:21 <devkulkarni> although let me check if destroy_assembly was part of the public interface of the deployer
17:19:40 <devkulkarni> actually it is :(
17:20:01 <devkulkarni> look at the deployer/noop.py
17:20:01 <ashishjain> james_li: yeah searching through the code it just being called by assembly_handler
17:20:30 <james_li> thanks for verification
17:20:56 <devkulkarni> ashishjain: we want to deprecate assembly_handler eventually
17:21:21 <devkulkarni> so it is probably okay if we modify the destroy assembly method the way you are doing it
17:21:23 <ashishjain> devkulkarni: you mean it is deployer/handlers/noop.py
17:21:30 <devkulkarni> ashishjain: yes
17:22:45 <ashishjain> devkulkarni: But is the destroy_assembly being called from here?
17:23:29 <ashishjain> I am sorry but am I missing something here?
17:23:58 <devkulkarni> ashishjain: as you just noted, destroy_assembly is called from assembly_handler. Eventually we are planning to deprecate assembly abstraction
17:24:09 <devkulkarni> but right now it is still there
17:24:48 <devkulkarni> so I was wondering if there is a real necessity to remove call to assem.destroy from the exception handlers?
17:25:15 <devkulkarni> we could leave those calls there and remove them when we get rid of assembly abstraction
17:25:19 <ashishjain> devkulkarni: actually no & yes
17:26:02 <ashishjain> devkulkarni: line no 313 fails because of exception
17:26:40 <ashishjain> because we try to remove assembly again and this approached seemed better
17:26:48 <ashishjain> but as you said I will revert it back
17:26:56 <devkulkarni> ashishjain: I see..
17:27:27 <ashishjain> and instead break this call in line no 313 "objects.registry.Workflow.destroy(app_id)" into multiple lines of code so that we just remove plan & workflow here
17:27:38 <ashishjain> and not assembly
17:27:59 <devkulkarni> ashishjain: let me quickly look at workflow.destroy
17:28:16 <ashishjain> devkulkarni:thanks
17:29:12 <devkulkarni> ashishjain: ok.. so workflow.destroy is destroying everything, which is good
17:29:21 <devkulkarni> lets not break it up
17:29:26 <ashishjain> yeah that was the point
17:29:32 <ashishjain> than ?
17:29:49 <devkulkarni> I like the way you have line 313 right now
17:30:06 <devkulkarni> it is calling workflow.destroy which is going to destroy everything
17:30:23 <ashishjain> okay than we need to remove line number 236 & 213,
17:30:43 <devkulkarni> actually, I just wanted to discuss/debate that part
17:31:13 <devkulkarni> oh nm
17:31:37 <devkulkarni> is workflow.destroy also destroying heat stack?
17:32:26 <ashishjain> no it just removes entries from DB
17:32:47 <devkulkarni> ok, yes I just verified that
17:32:51 <ashishjain> line number 310 is taking care of it
17:33:34 <devkulkarni> in that case, the question that I have is, if we don't remove lines 236 and 213, what will happen?
17:33:58 <devkulkarni> I think it will be alright since those lines are part of the exception handling code
17:34:46 <devkulkarni> we can remove those lines when we eventually deprecate the assembly abstraction
17:35:04 <ashishjain> If we do not remove lines 213 & 236 there will another call made using Workflow.destroy to remove the entries from the db whcih will eventually hit an exception
17:35:19 <ashishjain> not sure if that part of the code has got exception handling
17:35:34 <devkulkarni> ok, let me check
17:35:52 <ashishjain> checked it has got
17:36:20 <ashishjain> aah but there is an issue
17:37:04 <ashishjain> the code execution will move out of the loop very first time it hits an exception while deleting assembly and hence will not remove any further entries
17:37:26 <ashishjain> moreover it will not remove any entries for plan as well
17:37:55 <devkulkarni> you mean in workflow.destroy method
17:38:02 <ashishjain> yes correct
17:38:46 <devkulkarni> ashishjain: ok, it is now clear to me that we do need to remove lines 212 and 236
17:39:17 <ashishjain> devkulkarni: thanks for your review
17:39:34 <devkulkarni> james_li, ashishjain: I will add my comment to the patch
17:40:15 <ashishjain> sure, I have modified the unit test cases as well per the patch
17:40:55 <devkulkarni> ashishjain: thanks
17:41:23 <devkulkarni> ashishjain: if we don't want to remove those two lines then your suggestion is to modify Workflow.destroy method
17:41:56 <devkulkarni> to add exception handler around each delete call, right?
17:42:13 <ashishjain> devkulkarni: yes that would be the way forward I guess
17:42:38 <ashishjain> but that does not seem to be an elegant solution
17:42:50 <devkulkarni> thinking/debating
17:42:56 <devkulkarni> yes, agree to that
17:43:25 <devkulkarni> just thinking if we can somehow not modify the semantics of destroy_assembly method
17:43:59 <ashishjain> agreed
17:44:46 <devkulkarni> can't think of a way right away
17:44:57 <devkulkarni> if I think of something, I will add it to the comment
17:45:15 <devkulkarni> otherwise, we can move forward with the approach that you have
17:45:23 <ashishjain> can we
17:45:42 <devkulkarni> cool.. great discussion
17:45:43 <ashishjain> modify the assembly_handler code to accomodate
17:45:55 <ashishjain> the assembly details removal from DB
17:46:03 <ashishjain> anyways it would be sunset in sometime
17:46:26 <devkulkarni> ashishjain: true about sunset
17:46:35 <ashishjain> and keep the bes possible solution for our apps & workflow
17:47:00 <devkulkarni> ashishjain: about modifying assembly_handler.. we cannot do that since we want to destroy an assembly only after the heat stack is deleted
17:47:10 <devkulkarni> and deletion of heat stack happens in deployer
17:47:13 <ashishjain> aah okay
17:47:15 <ashishjain> got it
17:47:44 <devkulkarni> agree about keeping the solution forward looking
17:47:46 <ashishjain> I was also facing similar problem and thats why had to move all the code to deployer about removal from db tables
17:47:54 <devkulkarni> yep
17:48:19 <devkulkarni> that is exactly the reason why we cannot delete db rows directly from workflow handler
17:48:55 <devkulkarni> alright.. let me jump ahead to the spec on micro-service architecture
17:49:08 <ashishjain> one last point
17:49:14 <devkulkarni> ashishjain: sure
17:49:34 <ashishjain> can we in any way figure out if the call emanate from assembly_handler or app_handler
17:49:56 <ashishjain> no I think
17:50:33 <devkulkarni> we could by modifying one of them to add a header/flag to context
17:50:44 <devkulkarni> and then checking the context for that flag
17:51:00 <devkulkarni> were you thinking of using that as a hint of whether to delete an assembly or not?
17:51:07 <ashishjain> yeah correct
17:51:08 <devkulkarni> that could work
17:51:32 <devkulkarni> but seems like too much of work for something that we are not going to support in the long term
17:51:42 <ashishjain> I agree with you on this
17:51:53 <ashishjain> so you can probably suggest what could be best
17:51:55 <devkulkarni> good idea though
17:52:06 <devkulkarni> the best course is what you have currently
17:52:06 <ashishjain> and I will try to implement it
17:52:23 <ashishjain> thanks
17:52:37 <devkulkarni> let me add a comment in reply to james_li's comment about why we need to remove those lines
17:52:49 <devkulkarni> that way there will be a record
17:52:59 <ashishjain> okay
17:53:10 <devkulkarni> I will also link today's chat transcripts with it
17:53:20 <devkulkarni> alright..
17:53:34 <devkulkarni> we have only few minutes remaining
17:53:47 <ashishjain> and we got lots to discuss I guess
17:54:16 <devkulkarni> yeah.. we can do that in solum channel tomorrow and throughout the week..
17:54:47 <devkulkarni> for datsun180b and james_li: want to get your attention on https://review.openstack.org/#/c/254729/ and https://bugs.launchpad.net/solum/+bug/1517588
17:54:47 <openstack> Launchpad bug 1517588 in Solum "delete-heat-stack-when-app-is-deleted" [High,In progress] - Assigned to Ashish (ashish-jain14)
17:55:01 <devkulkarni> let me quickly give brief summary on both
17:55:27 <devkulkarni> the first review is of a spec which outlines how to add support for multi-service applications in solum
17:55:42 <devkulkarni> I have outlined requirements, approach, etc.
17:55:47 <james_li> ncie
17:55:48 <james_li> nice
17:56:08 <devkulkarni> james_li, datsun180b: yep.. whenever you get a chance, please review the spec
17:56:16 <devkulkarni> this is a first cut
17:56:36 <devkulkarni> datsun180b: your input on the changes to the app file format will be valuable
17:56:48 <datsun180b> sure
17:56:56 <devkulkarni> james_li: your input on the changes that need to be made to solum-worker and solum-deployer would be valuable
17:57:07 <ashishjain> that is a good spec I can see support for kubernetes and docker-compose, do we not plan magnum?
17:57:16 <devkulkarni> both of yours comments on the entire spec would be valuable
17:57:31 <devkulkarni> ashishjain: we do plan to integrate with magnum
17:57:56 <devkulkarni> although, for supporting multi-service applications we don't necessarily need magnum
17:57:58 <ashishjain> since magnum already does compose & kubernetes I think we just integrate magnum
17:58:24 <devkulkarni> I think magnum supports swarm and kubernetes
17:59:02 <devkulkarni> my thinking was that we can get an initial multi-service app poc without having to worry about magnum
17:59:19 <ashishjain> sorry you are correct I think it is swarm and kubernetes
17:59:21 <devkulkarni> we can directly use docker-compose on Heat
17:59:28 <ashishjain> not sure if mesos is in their plan
17:59:43 <devkulkarni> yes, mesos is in their plan..
17:59:51 <devkulkarni> probably they already support it
18:00:18 <devkulkarni> alright.. it is time
18:00:30 <devkulkarni> thanks ashishjain, datsun180b, james_li for joining today
18:00:34 <devkulkarni> see you next tuesday
18:00:34 <ashishjain> yes you are correct they already support mesos
18:00:38 <ashishjain> thanks devkulkarni
18:00:47 <ashishjain> thanks james_li datsun180b
18:00:55 <devkulkarni> #endmeeting