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