22:00:00 <tomblank> #startmeeting Solum Team Meeting
22:00:01 <openstack> Meeting started Tue Jul 22 22:00:00 2014 UTC and is due to finish in 60 minutes.  The chair is tomblank. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:06 <openstack> The meeting name has been set to 'solum_team_meeting'
22:00:10 <pgpus> Is release 2014.2 on track?
22:00:28 <tomblank> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-07-22_2200_UTC
22:00:39 <tomblank> #topic Roll Call
22:00:48 <muralia> murali allada
22:00:49 <datsun180b> Ed Cranford
22:00:50 <asalkeld> o/
22:00:52 <james_li> James Li
22:00:55 <ravips> Ravi Sankar Penta
22:00:57 <tomblank> Tom Blankenship, pro-tem Chair
22:01:01 <PaulCzar> Paul Cz
22:01:12 <lecalcot> Lee Calcote
22:01:32 <pgpus> prakash r
22:02:09 <bmittapa> Balaji Mittapalli
22:02:12 <aratim> Arati Mahimane
22:02:51 <tomblank> #topic Announcements
22:03:34 <tomblank> anyone have any announcements?
22:04:02 <asalkeld> the pipeline patches are working nicely:)
22:04:06 <pgpus> Just I am new to this group .
22:04:16 <datsun180b> well hello and welcome pgpus
22:04:16 <muralia> welcome pgpus
22:04:25 <tomblank> pgpus: We don't have a lot on the agenda today so we'll get to open discussion soon.
22:04:29 <muralia> woot! for pipelines
22:04:30 <tomblank> pgpus: welcome...
22:04:33 <ravips> Hi Prakash
22:04:55 <pgpus> Thanks well lets shoot for pipeline!!!
22:05:01 <tomblank> asalkeld: that's great news...
22:05:13 <tomblank> #topic blueprint/task review
22:05:42 <tomblank> asalkeld: thanks for the update on the pipeline.  any other details or status you want to share?
22:05:56 <asalkeld> no, all good
22:06:01 <muralia> angus, what are all the tasks that are executed by the pipelines today?
22:06:13 <asalkeld> build & deploy
22:06:25 <muralia> ok.
22:06:29 <asalkeld> we need some work to the builder api to do unit tests
22:06:37 <asalkeld> (not hard)
22:06:48 <muralia> nice work
22:06:50 <asalkeld> I sent datsun180b a patch
22:07:14 <tomblank> yes, good job asalkeld!
22:07:47 <datsun180b> shouldn't be too tough to wedge unit tests in there
22:08:28 <PaulCzar> do we now officially have a reliance on mistral ?
22:08:52 <asalkeld> PaulCzar, if you want to use pipeline code
22:08:54 <asalkeld> yes
22:09:11 <PaulCzar> asalkeld: okay, so the old pre-pipeline is still usable ?
22:09:32 <asalkeld> I think so, i haven't used it in a while
22:09:44 <asalkeld> (should be removed tho')
22:09:54 <asalkeld> but gpilz might want to use it
22:10:04 <asalkeld> not sure what to do about that tho'
22:10:17 <muralia> im able to still deploy the demo ghost app with the latest code
22:11:00 <lecalcot> muralia, are you still able to deploy PaulCzar's "ex1" app with the latest code?
22:11:18 <muralia> havent tried that
22:11:51 <pgpus> Is build a task or part of workbook in mistral?
22:11:52 <pgpus> id
22:11:52 <pgpus> workbook_name
22:11:52 <pgpus> task
22:11:52 <pgpus> context
22:11:53 <pgpus> state
22:12:21 <asalkeld> pgpus, build is a task
22:12:42 <pgpus> Ok so workbook is build+deploy for solumn
22:13:01 <asalkeld> yip, have a look here: https://review.openstack.org/#/c/95709/
22:13:06 <pgpus> thanks
22:13:37 <tomblank> Subject: Private git repo integration (ravips)
22:13:47 <tomblank> ravips: can you give us an update on your work?
22:13:52 <ravips> I did not find time to work on this for the last 2 weeks, resumed the task yesterday
22:14:01 <tomblank> #link   https://blueprints.launchpad.net/solum/+spec/support-private-github-repos Private Repo Blueprint
22:14:19 <ravips> added unit tests and incorporated WIP feedback, currently testing my changes..still need to add some functional tests
22:14:32 <ravips> hoping to submit final patch in couple of days
22:14:48 <ravips> I find solum.common.exception not useful most of the time..
22:15:14 <ravips> have to sprinkle logs/backtrace to figure out the problem..
22:15:36 <datsun180b> there's an open bug about "more descriptive exceptions", though i can't remember who submitted it
22:15:38 <ravips> I think we can improve error msgs in the logs
22:16:19 <lecalcot> ravips, with regard to this blueprint, we've just embedded Barbican into our upcoming product release. Let me know if we can be of help as you go to use it.
22:16:55 <ravips> lecalcot: need this patch https://review.openstack.org/#/c/108842/ in python barbican client..please review
22:17:57 <tomblank> ravips: thanks for the update.
22:18:00 <ravips> no more updates from my side
22:18:09 <tomblank> lecalcot: thanks!
22:18:29 <tomblank> Subject Chained Trusts (asalkeld, julienvey)
22:18:43 <lecalcot> tomblank, ravips, sounds real good. We're meeting with Lisa and team at Rackspace on Friday. Will raise it up.
22:19:09 <asalkeld> tomblank, so this is not a short term problem as I create an empty heat stack when the pipeline is created
22:19:37 <ravips> lecalcot: thanks
22:19:38 <asalkeld> then we can update that stack with a trust token with no problem
22:20:19 <asalkeld> but going forward, if we have multiple heat stacks that we need to update it would  be nice to have chained trusts
22:20:46 <tomblank> asalkeld: understand and thanks.
22:20:47 <asalkeld> tho' I believe shardy has backed off implementing that bp for now
22:21:03 <asalkeld> (doing higher priority work)
22:21:16 <asalkeld> tho' the bp is accepted I think
22:21:20 <PaulCzar> asalkeld: so if we use heat to manage any customer resources we get to piggy back off the stack ?   but if we have stuff that doesn’t have a heat resource, we might not be able to do it on behalf of user ?
22:21:37 <pgpus> If you are implementing one stack for deployment it should  be simpler
22:22:06 <asalkeld> PaulCzar, yes - it needs a heat stack
22:22:25 <asalkeld> tho' it's easy to make new resource types
22:22:38 <asalkeld> I don't think that is a problem
22:22:51 <pgpus> You can create an YAML descriptor for the stack you deploy for the app you mange
22:23:26 <asalkeld> pgpus, you can have a custom heat template
22:23:37 <pgpus> The descriptor can list resoources
22:24:11 <asalkeld> tomblank, I think chain trusts have run dry
22:24:14 <pgpus> sure custom will be fine
22:24:24 <tomblank> #topic Open Discussion
22:24:53 <gpilz> I think I found a bug in the API w/respect to serializing the "plans" and "plan" resources
22:25:01 <gpilz> it only does YAML now
22:25:06 <gpilz> even if you ask for JSON
22:25:14 <ravips> asalkeld: keystone oauth support will solve this problem?
22:25:25 <asalkeld> ravips, no
22:25:49 <asalkeld> basically we have to work on keystone to implement chained trusts
22:26:20 <asalkeld> gpilz, there might be a bug for that
22:26:28 <muralia> gpilz, do open a bug for it if there isisnt one. If im not wrong, pierre was working on that
22:26:49 <gpilz> oh - this is still work in progress?
22:27:28 <james_li> asalkeld: is the BP this one : https://blueprints.launchpad.net/keystone/+spec/trusts-redelegation
22:27:42 <james_li> asalkeld: for chained trust?
22:27:53 <asalkeld> I believe so
22:28:50 <pgpus> There no specs on that for work to do
22:29:14 <asalkeld> there is a keystone-spec review
22:29:16 <datsun180b> #link https://bugs.launchpad.net/solum/+bug/1331093 for gpilz' comment
22:29:17 <uvirtbot> Launchpad bug 1331093 in solum "Plan API should return json/yaml as accept header specifies" [Critical,Triaged]
22:29:51 <datsun180b> assigned to stannie and marked j2
22:30:21 <gpilz> great
22:30:25 <PaulCzar> on that bug … surely the API should always respond with json, and the client could convert to yaml ?
22:31:06 <datsun180b> i think the original intent was to accept yaml and respond in kind instead of crunching yaml and storing it as json
22:31:07 <asalkeld> api should return what you ask (Accept: ..)
22:31:33 <datsun180b> so the thinking was "why not just accept yaml, store yaml, and return yaml" since our plans are yaml
22:31:47 <asalkeld> #link https://github.com/openstack/keystone-specs/blob/master/specs/juno/trusts-redelegation.rst
22:31:53 <gpilz> the question is "what do you return in the absence of an 'Accept' header?"
22:31:59 <gpilz> i.e. what is the default behavior
22:32:09 <datsun180b> i want to say json is the default for OS
22:32:18 <asalkeld> I'd guess json
22:32:19 <gpilz> that makes sense to me
22:32:26 <muralia> +1
22:32:31 <PaulCzar> json by default :)
22:32:36 <gpilz> seems weird that every other resource defaults to json - but these don't
22:32:42 <tomblank> +1
22:33:03 <PaulCzar> let’s convert everything to yaml.   said no-one ever.
22:33:25 <datsun180b> "Gosh, I wish this service responded with XML" --no one
22:33:29 <pgpus> python -c 'import sys, yaml, json; json.dump(yaml.load(sys.stdin), sys.stdout, indent=4)' < file.yaml > file.json
22:33:29 <pgpus> 2013-04-24 00:28:55
22:33:29 <pgpus> User: tebeka
22:33:29 <pgpus> Functions: python
22:33:29 <pgpus> 0
22:33:29 <pgpus> Up
22:33:30 <pgpus> Down
22:33:30 <pgpus> Convert YAML to JSON
22:33:31 <pgpus> Converts YAML file to JSON.
22:33:45 <gpilz> you haven't seen my SOAP YAML Binding spec yet ….
22:33:58 <gpilz> :)
22:34:09 <datsun180b> pgpus: hah, i pasted about that into #solum earlier
22:34:11 <asalkeld> gpilz, wsme support soap if you want it;)
22:34:13 <pgpus> may be not , fine if you do have solution for it
22:34:41 <datsun180b> so from the bug it looks like the yaml/json thing is already identified as a big red problem and stannie's already on it
22:35:00 <asalkeld> gpilz, https://pypi.python.org/pypi/WSME-Soap/0.4.1
22:35:11 <asalkeld> (we use wsme)
22:35:23 <gpilz> excuse me - I think I threw up in my mouth a little
22:36:28 <tomblank> other topics?
22:36:44 <datsun180b> now that i'm thinking about it we may want to add a --json or --yaml flag to the CLI when that becomes relevant
22:36:55 <gpilz> FWIW - I'm working on the spec for the Solum CAMP API
22:37:08 <pgpus> Is this build deploy tarrgeted for 2014.2 Juno release?
22:37:11 <datsun180b> or just some kind of --accept= flag anyway
22:37:49 <lecalcot> Here's a newbie question - in terms of workflow, where is Solum currently delineating between use of heat and use of mistral?
22:39:22 <pgpus> I thought deplo was targeting Heat and build was using mistral workflow?
22:39:25 <asalkeld> lecalcot, we use mistral for the steps
22:39:39 <asalkeld> so kicking off the build, deploy
22:39:50 <asalkeld> but one of the tasks is heat-stack-update
22:40:02 <pgpus> I see
22:40:04 <asalkeld> that is where we get heat to update the stack
22:40:47 <asalkeld> the idea is we can then fit in more stages like functional /unit test
22:40:50 <asalkeld> easily
22:40:50 <PaulCzar> if people have time I’d love to see a quick review turnaround of this - https://review.openstack.org/#/c/108523/  …  got some POC stuff I’m working on that would benefit from it … and I’d rather not mess with pulling patches
22:41:28 <datsun180b> well i think it's great
22:43:23 <PaulCzar> datsun180b maybe not great,  but it’s not the worst code ever written
22:43:27 <asalkeld> well it would be great if we got the pipeline code in:-O
22:43:40 <PaulCzar> asalkeld: you aren’t allowed to have nice things
22:43:51 <lecalcot> thanks, asalkeld. I see the line of delineation now. Is heat-update a Juno BP?
22:43:51 <datsun180b> hey you two remember that time when i wrote that and you didn't
22:43:57 <tomblank> asalkeld: +1
22:44:32 <asalkeld> lecalcot, the pipeline stuff is for this release
22:44:50 <pgpus> That is helpful saves time for tests and should it not be called noBuid.nodeploy?
22:45:00 <asalkeld> (we currently use heat update, just run more manually)
22:45:21 <pgpus> ok
22:46:17 <asalkeld> sorry I have to go take kids to school
22:46:20 <tomblank> any other topics?  if not, we can end a few minutes early.
22:46:21 <asalkeld> later...
22:46:41 <datsun180b> pgpus: you can't deploy what you isn't built
22:46:50 <datsun180b> or what isn't built
22:47:16 <datsun180b> english is hard
22:47:23 <pgpus> goot answer I like it.
22:48:20 <tomblank> thanks everyone.
22:48:39 <tomblank> feel free to continue or ask any questions in #solum.
22:48:44 <tomblank> #endmeeting