21:00:16 <devkulkarni> #startmeeting Solum Team Meeting
21:00:17 <openstack> Meeting started Tue Aug 18 21:00:16 2015 UTC and is due to finish in 60 minutes.  The chair is devkulkarni. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:27 <openstack> The meeting name has been set to 'solum_team_meeting'
21:00:41 <devkulkarni> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-08-18_2100_UTC agenda for today
21:00:49 <devkulkarni> #topic Roll Call
21:00:52 <devkulkarni> Devdatta Kulkarni
21:00:53 <datsun180b> Ed Cranford
21:00:55 <muralia> murali allada
21:00:55 <gpilz1> Gil Pilz
21:01:00 <mkam> Melissa Kam
21:01:14 <devkulkarni> hi ed, murali, gpilz, mkam
21:01:20 <devkulkarni> nice to see you all :)
21:01:37 <muralia> hey all.
21:01:41 <devkulkarni> today adrian_otto is out
21:01:42 <datsun180b> right back at you
21:02:02 <devkulkarni> please take a few minutes to check our agenda
21:02:15 <devkulkarni> I have mostly reviews to share/discuss today
21:02:38 <devkulkarni> I will go through the usual topics in any case
21:02:49 <devkulkarni> #topic Announcements
21:02:58 <devkulkarni> I don't have any
21:03:00 <randallburt> oh hello there
21:03:04 <devkulkarni> hi randallburt
21:03:09 <devkulkarni> we are just getting started
21:03:12 <randallburt> k
21:03:20 <randallburt> sorry for being late
21:03:24 <devkulkarni> nice to see you here
21:03:27 <devkulkarni> no worries
21:03:47 <devkulkarni> randallburt here is the agenda link for today: https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-08-18_2100_UTC
21:03:53 <randallburt> yep, caught up
21:03:57 <devkulkarni> cool
21:04:46 <devkulkarni> okay, since no announcements from anyone, moving on to next topic
21:04:56 <devkulkarni> #topic Review Action Items
21:05:34 <devkulkarni> last week there were no action items
21:06:00 <devkulkarni> #topic Blueprint/Task Review and Discussion
21:06:12 <devkulkarni> ok, in this topic I have at least three subtopics
21:06:19 <devkulkarni> hi vijendar
21:06:31 <vijendar> devkulkarni: hi
21:06:54 <devkulkarni> folks please welcome vijendar to solum team meeting
21:07:11 <muralia> hey hey welcome
21:07:29 <vijendar> thanks
21:07:32 <devkulkarni> vijendar will be participating in solum related activities soon
21:07:35 <randallburt> o/
21:07:36 <datsun180b> cool
21:08:00 <devkulkarni> ok, so about review items..
21:08:06 <devkulkarni> first one is this:
21:08:15 <devkulkarni> (devkulkarni) Parsing ipv4 subnet-id from neutron. Please review (https://review.openstack.org/#/c/213854/2)
21:08:24 <devkulkarni> let me give bit of background on this one
21:08:43 <devkulkarni> I was noticing that on devstack our app deployments had been failing with an error from heat
21:08:57 <devkulkarni> to the effect 'bad floating-ip'
21:09:12 <devkulkarni> and the floating-ip being reported was ipv6 ip
21:09:18 <devkulkarni> this was not a consistent error
21:09:31 <devkulkarni> it was only ocassional
21:10:02 <devkulkarni> after debugging a bit I realized that the subnet-id that we are picking from neutron has to be for the ipv4 subnet
21:10:15 <devkulkarni> in our code we were not checking this condition
21:10:22 <devkulkarni> the above patch adds this check
21:10:36 <devkulkarni> randallburt and muralia has reviewed it
21:10:45 <devkulkarni> I need one more +2 on it
21:10:58 <devkulkarni> randallburt: good points on the patch
21:11:05 <randallburt> thanks
21:11:11 <datsun180b> i can look
21:11:12 <devkulkarni> thanks to you actually :)
21:11:18 <devkulkarni> datsun180b: that will be helpful
21:11:34 <randallburt> np, muralia found it first, I just ran off at the mouth more :)
21:11:43 <muralia> :)
21:11:47 <devkulkarni> oh, okay
21:11:55 <devkulkarni> thanks to muralia in that case (and also to you randallburt)
21:12:14 <devkulkarni> good to have you all keeping an eye on such things
21:12:30 <devkulkarni> so datsun180b, take a look whenever you get a chance
21:12:45 <devkulkarni> moving on to the next one..
21:12:56 <devkulkarni> (devkulkarni) Parsing IP address of server from Heat. Please review (https://review.openstack.org/#/c/213940/)
21:13:03 <devkulkarni> some background on this one..
21:13:25 <devkulkarni> In Solum we need the ip address of the server created by heat
21:14:05 <devkulkarni> the parsing logic that we have implemented makes an assumption about the location of IP address. But turns out that that assumption is wrong.
21:14:29 <devkulkarni> Heat returns two things as part of output_value — one is the IP address and another is the URL.
21:14:34 <randallburt> yeah, never good to address outputs (or any key-value) by index in heat
21:14:43 <devkulkarni> we don't want to pick the URL because
21:15:00 <devkulkarni> in Solum we construct the URL ourselves (we need to do that because..)
21:15:40 <devkulkarni> an app may have multiple ports and we construct the url in the following format: http://<ip>:[port1, port2] etc.
21:15:43 <devkulkarni> this is by design.
21:16:01 <devkulkarni> so, we want to parse only the IP address from heat output
21:16:19 <devkulkarni> and our current code was not checking whether what we are parsing is indeed the IP address or not
21:16:34 <devkulkarni> so the above patch fixes this issue
21:16:46 <devkulkarni> vijendar: you might want to take a look at this patch
21:17:08 <devkulkarni> randallburt, muralia: thanks for your reviews on this patch
21:17:10 <vijendar> I am looking at that patch now
21:17:16 <devkulkarni> vijendar: cool
21:17:37 <devkulkarni> datsun180b: if you get a chance please take a look at this one too
21:17:48 <devkulkarni> it also needs one more +2
21:17:52 <datsun180b> pretty straightforward
21:18:06 <devkulkarni> randallburt: good point about not depending on the order of key-values
21:18:35 <devkulkarni> btw, both the above issues were cause of apps not getting deployed on devstack
21:19:11 <devkulkarni> mkam, randallburt: do you think our rackspace deployment would have been occasionally failing due to this issue as well?
21:19:20 <randallburt> devkulkarni:  could be
21:19:42 <devkulkarni> I think so too..
21:19:43 <randallburt> as I said, never guaranteed to get the right output using just an index
21:19:56 <devkulkarni> yeah.. should remember that
21:20:31 <devkulkarni> randallburt: btw, thanks for suggesting to break up the review
21:20:44 <devkulkarni> hopefully that helped in reviewing
21:21:02 <devkulkarni> which brings me to the next item today..
21:21:10 <devkulkarni> (devkulkarni) Workflow resource related patches. Please review.
21:21:24 <datsun180b> these will take a little more time
21:21:31 <devkulkarni> yes..
21:21:42 <randallburt> nice breakdown though
21:21:48 <devkulkarni> so I broke up ed's WIP workflow patch into three patches
21:21:59 <devkulkarni> randallburt: thanks
21:22:24 <devkulkarni> it was in anticipating your -1 to original patch :P
21:22:41 <randallburt> lol
21:22:50 <devkulkarni> on a serious note though.. the original workflow wip patch was about 400 lines
21:22:56 <devkulkarni> without tests
21:23:10 <devkulkarni> so I thought it will be good to just break it up into logical pieces
21:23:11 * datsun180b whistles tuneless and avoids eye contact
21:23:38 <devkulkarni> datsun180b: he he.. actually your WIP has been tremendously helpful
21:23:51 <devkulkarni> no need to avoid eye contact :)
21:24:06 <devkulkarni> muralia: I saw your comment about tests for the workflow_handler
21:24:09 <devkulkarni> yes, I will add those
21:24:18 <devkulkarni> right now I am in the middle of adding tests for the objects
21:24:36 <muralia> cool. also, i added a lot of comments about using the app uuid instead of the app_id.
21:24:42 <devkulkarni> oh right
21:24:47 <devkulkarni> wanted to discuss about that
21:24:51 <devkulkarni> good that datsun180b is here too
21:25:13 <devkulkarni> I remember it was a conscious decision by datsun180b to suggest that we use id instead of uuid
21:25:23 <devkulkarni> will be good to discuss that today
21:25:37 <devkulkarni> datsun180b, randallburt: thoughts?
21:25:52 <devkulkarni> here are two points to consider
21:26:06 <datsun180b> i think code inertia was one reason
21:26:27 <devkulkarni> 1) uuids does not help indexing, but they are unique
21:26:54 <devkulkarni> 2) most of other solum objects have both id and uuid, and it has been sometimes confusing which one to use
21:27:22 <devkulkarni> although in the api/cli it is clear that we prefer uuids
21:27:28 <devkulkarni> like rest of the openstack services
21:27:47 <muralia> yes.
21:28:10 <devkulkarni> from the cli point of view
21:28:26 <devkulkarni> I think having uuids is conforming to other services
21:28:33 <datsun180b> agreed
21:28:34 <devkulkarni> so I think that would make sense
21:29:03 <devkulkarni> datsun180b: was there some other reason that we did not add uuid to workflow models?
21:29:15 <randallburt> sorry, was distracted. uuid
21:29:23 <randallburt> its just how its done
21:29:40 <datsun180b> devkulkarni: they have a uuid, but the field's called id
21:30:01 <datsun180b> at least i seem to recall that was the case at one point
21:30:05 <devkulkarni> datsun180b: oh I see.. but that will get confusing
21:30:10 <randallburt> so why both? one is a database id and one is the resource "id"?
21:30:11 <muralia> yes
21:30:28 <devkulkarni> randallburt: was about to ask that.. do we need both?
21:30:33 <datsun180b> i don't think we do
21:30:49 <datsun180b> doesn't do us much good to have the incrementing id
21:31:00 <randallburt> in general, the resource key and what the user interacts with is called "id". If you have a separate identifier, it usually for db optimization of some sort or some other legacy hooey
21:31:30 <datsun180b> ^ so call it id, but make it uuid-shaped?
21:31:37 <randallburt> in heat, some things have database ids so that we can return them in the order they came in (like events and such)
21:31:50 <devkulkarni> hmm.. thinking about it more.. actually keeping the autoincrementing id as another field is not bad
21:32:09 <datsun180b> workflows should/will have a sequence id scoped to the parent app
21:32:11 <randallburt> but on the user-side, they all have uuid "id"s as far as the api is concerned
21:32:28 <randallburt> so that should sort that then, datsun180b
21:32:40 <datsun180b> right, i think you and i agree randall
21:33:07 <devkulkarni> wait..
21:33:45 <devkulkarni> are we saying that we will keep only one field in the workflow model — call it id, but which is shaped like uuid?
21:33:58 <devkulkarni> or are we saying we will keep two fields
21:33:59 <datsun180b> that's what i thought i had in my wip
21:34:04 <devkulkarni> id and uuid
21:34:37 <devkulkarni> datsun180b: but how could a uuid be used as a sequence id?
21:34:50 <datsun180b> well it can't
21:35:00 <datsun180b> https://review.openstack.org/#/c/204164/3/solum/api/controllers/v1/datamodel/workflow.py does have id and uuid
21:35:11 <datsun180b> my memory's a little foggy about it i guess
21:35:26 <devkulkarni> okay, yes I see both of them
21:35:35 <devkulkarni> which makes sense
21:35:48 <devkulkarni> let me check back on the patches that I submitted
21:36:00 <devkulkarni> may be I missed having both in my patches
21:36:18 <datsun180b> i guess keep them both, refer to them specifically in the code, but any time we ask a user for an "id" or give them an "id" it'll be 128 bits in hexadecimal
21:36:37 <devkulkarni> yes, that makes sense
21:36:57 <devkulkarni> muralia, randallburt: thoughts?
21:37:26 <datsun180b> in the case of workflow we will need to maintain an order
21:37:43 <muralia> sure. thats what we are doing with other resources too. i was hoping we can remove the id and then change the other resources to use only uuids later
21:38:32 <devkulkarni> muralia: I see. I think for indexing reasons it will be good to keep the ids around
21:38:38 <muralia> ok.
21:39:01 <devkulkarni> datsun180b: what do you mean by need to maintain order for workflows for an app?
21:39:23 <devkulkarni> would be referring to "give me logs of the 3rd workflow for this app"?
21:39:37 <datsun180b> right, that's the case
21:39:41 <devkulkarni> or would we rather say — "give me logs of the workflow-id for this app"?
21:39:50 <datsun180b> my client wip covers both of those
21:40:01 <devkulkarni> datsun180b: I see.
21:40:21 <datsun180b> the idealized future included actions like "deploy the build from WF 35"
21:40:26 <devkulkarni> in any case, as long as we have autoincrementing ids we should be able to satisfy the ordered indexing
21:41:06 <devkulkarni> datsun180b: yes.
21:41:42 <devkulkarni> great discussion.. any more thoughts on this topic?
21:42:06 <datsun180b> so your patches are intended to be merged i take it
21:42:14 <datsun180b> they're not wips, that is?
21:42:19 <devkulkarni> which ones?
21:42:22 <devkulkarni> the workflow ones?
21:42:29 <devkulkarni> they are not yet ready ready
21:42:32 <devkulkarni> I need to add tests
21:42:32 <datsun180b> the WF ones (the IP ones are merging already)
21:42:44 <devkulkarni> I can mark them as WIPs
21:42:52 <datsun180b> likely a good idea
21:42:58 <devkulkarni> doing that now
21:43:09 <datsun180b> i do want to mention that since my fingerprints are on them i don't know that i should give them any +2s
21:43:19 <devkulkarni> datsun180b: makes sense
21:43:26 <devkulkarni> james_li is out today
21:43:38 <devkulkarni> but I will be reaching out to him for reviewing them
21:44:24 <devkulkarni> datsun180b: btw, I marked your client patch as WIP
21:44:30 <devkulkarni> so that we don't accidentally merge it
21:44:50 <datsun180b> saw that. do you want me to keep the solum WIP up, or do you have what you need from it already?
21:45:04 <datsun180b> the client one still has its use
21:45:21 <devkulkarni> I would like to have the solum WIP up just a bit longer
21:45:36 <datsun180b> that's an easy wish to grant
21:45:37 <randallburt> you can abandon it and it won't go away
21:45:39 <devkulkarni> it is easier to go back to check on things as everything is a single patch
21:45:51 <datsun180b> good point, randall
21:46:42 <devkulkarni> any other reviews to discuss?
21:46:58 <devkulkarni> I would have liked to discuss james_li's bash-to-python patches
21:47:02 <devkulkarni> but he is not around today
21:47:23 <devkulkarni> randallburt, vijendar: for those patches are are blocked on changes to config generator
21:47:53 <devkulkarni> have any ideas/insights on tackling the config generator issues?
21:48:07 <devkulkarni> we don't have to discuss it today though.. just wanted to check
21:48:22 <devkulkarni> s/are are/we are/
21:49:25 <devkulkarni> lets take that up when james_li is around
21:49:38 <devkulkarni> #topic Open Discussion
21:49:40 <randallburt> k. config generator is aweful and a bear to deal with
21:50:09 <randallburt> so, who's excited about "blueprints" vs the other stuff we discussed for pluggable deployers?
21:50:13 <devkulkarni> randallburt: :) .. hopefully it won't be too much of an issue
21:50:20 <devkulkarni> randallburt: oh that's right
21:50:30 <devkulkarni> we have that topic to discuss as well
21:50:43 <devkulkarni> let me refresh the options we have
21:51:30 <devkulkarni> so everyone — we are discuss about this spec: https://review.openstack.org/#/c/202254/3/specs/liberty/deployer_plugins.rst
21:51:46 <randallburt> blueprint, templates (boo!), layout, pattern, and something else
21:51:50 <devkulkarni> the issue is what to call the heat templates for different "architectural flavors" that solum will support
21:52:17 <datsun180b> is it too late to propose "kung fu style"
21:52:57 <gpilz1> "crouching tiger"
21:53:07 <randallburt> lol, winner
21:53:13 <datsun180b> "snake in eagle's shadow"
21:53:13 <devkulkarni> randallburt: my objection to blueprint is that it also has a meaning in openstack ecosystem
21:53:28 <datsun180b> i do agree that blueprint has a prior context
21:53:32 <randallburt> devkulkarni:  only to us developers. not to users
21:53:50 <devkulkarni> sure.. what are your thoughts on 'topology'?
21:53:55 <datsun180b> barf
21:54:01 <randallburt> oh yeah, that one. I like it less than blueprint
21:54:03 <devkulkarni> #link https://review.openstack.org/#/c/202254/2/specs/liberty/deployer_plugins.rst
21:54:11 <gpilz1> 'schematic' ?
21:54:13 <devkulkarni> check the comments
21:54:33 <devkulkarni> architecture schematic?
21:54:37 <devkulkarni> in that sense?
21:54:47 <gpilz1> yeah
21:54:55 <datsun180b> well for serious topology is probably the most apt of the terms
21:55:05 <datsun180b> and it has the least amount of baggage
21:55:18 <devkulkarni> datsun180b: +1 and +1
21:55:24 <randallburt> in the end, we can bikeshed forever. lets pick topology as the least offensive and give it a go.
21:55:45 <devkulkarni> randallburt: agreed
21:55:47 <datsun180b> +80 randallburt
21:55:53 <randallburt> ok, I'll update in the next few days and hopefully we can get it accepted
21:56:08 <devkulkarni> randallburt: awesome!! looking forward to it
21:56:34 <devkulkarni> randallburt: on a related note.. jvrbanac recently was mentioning that he has a plugin library that is an improvement on stevedore
21:56:48 <devkulkarni> jvrbanac: you around?
21:57:50 <devkulkarni> looks like jvrbanac is not around
21:58:04 <randallburt> imo that's a debate for a patchset. I'm dubious as to what's been "improved" and what deficiencies if any are addressed.
21:58:19 <devkulkarni> randallburt: in any case, thought of mentioning it here as we were discussing about stevedore
21:58:22 <randallburt> not looking forward to library wars tbh
21:58:25 <devkulkarni> randallburt: fair enough
21:58:39 <randallburt> cool. I look forward to the internet arguments :)
21:58:48 <devkulkarni> ha ha
21:59:15 <devkulkarni> anything else for today?
21:59:50 <randallburt> its time anyway
21:59:55 <devkulkarni> yeah
22:00:04 <devkulkarni> thanks all for joining today. great discussion today.
22:00:11 <devkulkarni> see you next week
22:00:14 <devkulkarni> #endmeeting