15:30:56 #startmeeting openstack-sdk-php 15:30:57 Meeting started Wed Apr 23 15:30:56 2014 UTC and is due to finish in 60 minutes. The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:31:00 The meeting name has been set to 'openstack_sdk_php' 15:31:17 Please state your name and any relevant association. 15:31:20 Matt Farina, HP 15:31:23 Sam Choi, HP 15:31:28 Shaunak Kashyap, Rackspace 15:31:30 Jamie Hannaford, Rackspace 15:32:04 Welcome folks 15:32:11 #topic Agenda 15:32:15 #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP 15:32:42 1. Intro to the PHP SDK if there is anyone new? (mfer) 15:32:42 2. Near term roadmap (mfer) 15:32:42 3. Blueprints / Bugs / Reviews (mfer) 15:32:42 5. Open Discussion (mfer) 15:32:44 4. JSON Schema (jamiehannaford) 15:32:56 is there anything else that should be added before we proceed? 15:33:19 I have nothing 15:33:27 me too 15:33:42 I think we can skip #1 because no one is new here. 15:33:54 #topic Near term roadmap 15:34:09 #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap 15:34:24 I have 1-2 things to discuss about near-term roadmap 15:34:31 I have this on the agenda because I had an action to link the items on the roadmap to the blurprints which I did 15:34:37 jamie_h what are they? 15:35:40 I've started work on the codebase yesterday and my immediate priority was addressing the tests. At the moment there seems to be 2 problems: the first is that integration tests (hitting the API) are intermingled with unit tests, which is causing incredible slowness. The second is that many of the integration tests initially didn't work with Rackspace APIs 15:36:24 jamie_h i'm aware of a couple issues that would cause problems. They are listed as bugs and samchoi is working on them right now 15:36:30 was there something else beyond that? 15:36:39 The patch I've submitted fixes the second issue, i.e. hotfixes which make tests work with Rackspace. I thought that was important before all other work commenced 15:36:58 I can liaise with Sam about other stuff he's working on 15:37:25 sure, it's still early here so I haven't seen the changes yet. Will look into it shortly 15:37:35 jamie_h we want the full test suite to work. for our testing purposes we'll be using devstack and our setup. devstack is is the openstack reference point. 15:37:45 jamie_h we do want all the tests passing 15:38:01 mfer yes, but I'm talking about splitting up integration tests from unit tests. Unit tests should not hit the API 15:38:14 They should mock out responses or dependent classes 15:38:21 Right now, that's not happening 15:38:30 most of the test suite is integration testing 15:38:35 exactly 15:38:48 Today I've split them out into separate phpunit groups 15:39:03 can we carve out some time to talk handling this at the openstack summit? 15:39:22 mfer I won't be at the summit, I'm at a talk in Italy then 15:39:28 ah, doh 15:39:36 mfer: same here, I'm at a talk in NYC 15:39:51 i'll miss meeting you two face to face 15:39:59 yeah, its a bummer 15:40:42 The main takeaway I have is that the initial code I've submitted in that patch (just the test fixes) is required for all other work to continue. I can look into extracting out the copyright headers into a separate patch 15:40:55 mfer is that okay with you? extracting the copyright stuff out 15:41:53 possibly. can you file a bug for this and detail out the issue as well. then link the commit to the bug. 15:42:12 sure 15:42:16 thanks 15:42:40 would it be easier to delete the current patch in Gerrit? Can that happen? 15:42:52 in the commit message on a link put Closes-Bug: 123 where 123 is the number 15:43:14 you can abandon a patch set 15:43:33 if you do the closes bug thing it will become a link to the bug in the review. it's useful for navigating the system 15:43:58 jamie_h you said there was 1-2 things. is there something else? 15:44:04 That's all I had 15:44:24 anything else about the near term roadmap? 15:44:36 I'm good 15:44:46 Me too 15:45:06 samchoi are you good? 15:45:32 I'm wondering what the priorities are, for the short term roadmap, in light of the testing issues jamie_h brought up 15:45:36 but we can save it for later 15:45:39 maybe open disc 15:46:08 samchoi I think there is always a priority to have the system working. in the open discussion i'd like to now talk about testing. 15:46:22 after than I think the priorities are numbered at the moment 15:46:23 ok, great 15:46:33 does anyone disagree with the ordering? 15:46:51 can we have json-schema before open discussion? since it follows on from blueprints 15:47:10 I would bump up the documentation a bit higher. I believe updating docs would be very helpful for newer contributors. 15:47:14 jamie_h yes. i re-numbered above but slipped up where i hit enter 15:47:49 samchoi: are you referring to user-facing docs (#8) or phpdoc (#3)? 15:47:58 user facing docs ycombinator 15:48:12 parts of the doc are out of date, due to a slew of recent changes 15:48:15 that's good because I've started working on them :) 15:48:19 I'll report in the BP section 15:48:24 thanks ycombinator 15:48:31 samchoi i'm not sure we'll get many more contributors until after the first basic usable release is out. 15:48:39 ycombinator btw, thanks for taking this on now 15:48:41 me neither 15:48:57 samchoi or I can somehow drum up some others at the summit. but, i'm not counting on it 15:48:57 mfer: do you feel I should switch to something higher up on the list? 15:49:04 since user-facing docs are #7 15:49:19 well, either for new contributors or even for jamie_h and ycombinator since they are getting into the codebase now 15:49:27 I'd hate for them to get into outdated docs, that's all 15:49:32 ycombinator while it's a lower priority I still consider it a priority and a good chunk of work 15:49:42 okay, thanks, I'll keep on keeping on 15:49:49 priority doesn't necessairly suggest order we tackle 15:49:56 though, maybe it should :) 15:50:04 bingo, that was my confusion 15:50:07 in any case, ycombinator i was happy to see you work on that 15:50:08 same 15:50:18 cool cool 15:50:25 are we ready to move on? 15:50:36 yeah 15:50:38 yes 15:50:40 yes 15:50:44 #topic Blueprints / Bugs / Reviews 15:51:02 #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z 15:51:09 there are currently two reviews listed 15:51:25 The .gitignore one I was reviewing when the meeting started 15:51:35 that is https://review.openstack.org/#/c/89528/ 15:51:49 jamie_h what does the .idea directory work with? 15:51:56 mfer PhpStorm 15:52:50 it's becoming increasingly more common to add .idea to your .gitignore - I looked at a handful of other projects 15:53:05 ok, i'll poke around at that shortly. 15:53:13 samchoi can you take a look at that as well? 15:53:18 sure mfer 15:53:53 great. 15:53:58 the other issue was https://review.openstack.org/#/c/89785/ 15:54:14 it contains two separate changes so I've asked that it be broken up. 15:54:20 yep 15:54:27 copyright issue needs further investigation 15:54:38 and the test fixes need consultation with Sam and a bug report 15:54:55 the copyright headers portion is a legal thing. that might take a little time to track down guidance on. these are logically separate as well 15:55:18 jamie_h if you hit any roadblocks on the bug portion please be sure to ping me 15:55:47 mfer will do. I'll probably ping you about closing the existing patch too 15:55:53 ok 15:55:58 any other discussion on that one? 15:56:07 not from me 15:56:18 i have one other. https://review.openstack.org/#/c/88315/ 15:56:35 this change to infra would notify us in the sdk room when something went into review 15:56:46 it's not landed yet but I thought it was worth automating 15:56:53 yeah, I've seen it in solum 15:56:55 I'm in favor of it 15:57:11 also, another thing: what does Jenkins actually do when it checks a patch? It doesn't seem to run any testsuite 15:57:24 unfortunately no. 15:57:35 correct, there are no gate tests at the moment 15:57:38 is that something we can add in, or is out of our hands? 15:57:38 the current setup works for python stuff. other languages and we run into problems 15:57:56 it's out of our hands right now. i've spoken with the infra folks about it 15:58:06 out of our hands for now not forever 15:58:15 I think that should be the top priority issue with infra 15:58:53 I do too. but, alas it's not. 15:59:29 they have some bigger issues in the short term 15:59:32 mfer: without knowing how the github mirroring of git.openstack.org works, could we setup a post-push hook in github to run the tests using something like travis? 15:59:53 ... until infra gets php testing going 16:00:18 ycombinator that would activate the hook after it's been merged though. I guess it's better than nothing 16:00:28 yeah, its not perfect but its better than nothing, imo 16:00:33 ycombinator i'd like to do that. i've been holding off asking them much about it lately because of other priorities. i was going to bring up the issue again at or after the summit 16:00:47 other priorities for them that is 16:01:32 ycombinator if you want to chance down an alternative setup in the short term that would be good 16:01:41 ok, I'll investigate 16:01:43 thanks 16:01:52 there are currently two listed bugs http://bugs.launchpad.net/openstack-sdk-php 16:02:00 they are related and samchoi is working on them 16:02:35 samchoi I think I ran into the stream wrapper default region one 16:02:56 and fixed it by pulling the region value out of the context options 16:03:00 jamie_h i expected you would. i reported it thinking of you 16:03:15 :) 16:03:15 mfer: jamie_h Yea the bugs aren't too bad, but I was holding off on submitting my changes until I have DevStack up and running 16:03:28 so that I'm able to test against a reliable environment 16:03:29 gotcha 16:03:55 there are two blueprints in progress as well https://blueprints.launchpad.net/openstack-sdk-php 16:04:14 i've started the multiple api version one https://blueprints.launchpad.net/openstack-sdk-php/+spec/multiple-api-versions 16:04:27 there's a spec at https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/Design/Multi-Version 16:04:35 did anyone want to have any discussion about this? 16:04:37 I've started (barely) the https://blueprints.launchpad.net/openstack-sdk-php/+spec/sphinx-docs one 16:04:49 process question: do we report progress about the BP here? 16:04:52 or how does that work? 16:05:07 mfer the blueprint you've referenced ties in heavily with schemas - are you happy with starting to write that code? 16:05:13 if you have something you want to talk about you can. but, this isnt' a standup 16:05:30 jamie_h yes. and i'm prepared for schema discussions 16:05:43 and how they relate 16:05:58 okay, so everything falls into its own version directory. Nearly all of a service's functionality is defined by its schema file - right? 16:06:20 Which utilizes classes, etc. inside the version directory 16:06:24 this change doesn't do the schema portion. just the versions live in their own directories. it's a small change 16:06:32 ah okay 16:06:41 I have 2 questions about the sphinx docs BP but I'm holding off until the multiple-api-versions discussion is done 16:06:49 micro changes. that's why i'm happy schemas has it's own blueprint 16:07:04 so what would the directory structure look like? 16:07:15 src / Identity / v3.0 / 16:07:36 src / OpenStack / Identity / v3.0 / 16:08:02 and inside 3.0 directory, would there be other standard folders? Is that covered in this blueprint? 16:08:13 like Iterator or Resource etc. 16:08:28 in that directory would be the thing to work with the service. this issue isn't dealing with what that thing is 16:08:36 okay 16:08:53 i'm intentionally keeping it vauge. the commit would keep the thing what's already in place. 16:09:07 and leave changes to the thing to come separately 16:09:19 which OpenStack services are you adding for now? Just Identity and Storage? 16:09:41 identity and storage is all. adding more would mean more refactoring. that's whey we didn't put more out there from the start 16:10:15 Today I worked on moving to a standard workspace structure, pretty much as you've outlined above with Identity and Storage as separate directories 16:10:26 and common stuff (like transport, exceptions) in a Common directory 16:10:57 ok 16:11:09 How shall I continue with that work? Wait until you've submitted a patch and then rebase? 16:11:38 sure. if you work on the bugs with sam i'll have my bit in for review here by tomorrow 16:11:54 okay 16:12:01 or, your work day might end first :) 16:12:23 anything else or can we move on to ycombinators stuff? I'd like to have time for the json schema stuff 16:12:31 I have nothing else 16:12:32 and we have 18 mintues left 16:12:37 okay - 16:12:37 ycombinator what are your questions? 16:12:40 mine should be quick 16:12:51 1. I've created a "spec" for the user facing docs here: https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/UserFacingDocumentation 16:12:55 nothing ther eyet 16:13:17 but: what is the process of getting all of your feedback on it? 16:13:58 ycombinator you can email me, email the dev mailing list, and/or ping me in IRC 16:14:07 as soon as I see any of this come through I'll jump on it 16:14:19 I do hope that samchoi and jamie_h jump in with feedback as well 16:14:22 okay, so there's no way of having the discussion in the wiki directly 16:14:23 we have a mailing list for the PHP SDK? Did I miss that 16:14:23 got it 16:14:34 ycombinator for now, maybe send it via e-mail to us all? 16:14:35 samchoi: its just openstack-dev with the openstack-sdk-php tag 16:14:42 samchoi no, all dev conversations go through the openstack dev list with a prefix for the project 16:14:48 ah i see 16:14:51 thanks 16:14:51 okay, mailing list it is 16:14:55 that's they way the openstack community does things 16:14:58 and question 2. based on Matt's and Anne's email responses to my questions, I'm going to focus on having Sphinx spit out HTML in a directory (like build/) for now 16:15:08 not worry about where they would be published eventually 16:15:18 good 16:15:19 I want to make sure everyone is okay with that scope for this BP 16:15:26 i'm ok with it 16:15:28 I'm happy with it 16:15:31 cool 16:15:31 ok 16:15:31 thanks 16:15:33 that was it 16:15:38 great 16:15:51 if everyone is ok with it, lets move on to json schema 16:16:01 sure 16:16:08 ok 16:16:08 #topic JSON Schema 16:16:36 jamie_h since this is your thing, can you present it? 16:16:47 Okay 16:17:21 So a few OpenStack services right now (Glance, Common, and possibly KeyStone) use json-schema to encapsulate data structures 16:17:44 The plan is to use json-schemas in the SDK as a way to define services like Swift, Nova, etc. 16:18:29 For example, HTTP operations will be clearly defined - with expected parameters, HTTP method types, URLs, etc. This avoids writing hundreds of lines of userland code which duplicates common functionality 16:19:01 It also serves as living documentation - allowing end-users to understand exactly what they're expected to enter for operations 16:19:21 Recently I've been working a light-weight library that allows schema files to be validated and consumed against live data 16:19:33 jamie_h: dumb question: will this account for variances when certain services use PUT instead of POST to do resource creation, etc. 16:19:39 s/account/allow 16:20:01 yes, exactly. All API operations have their own entry, and allows for differences, say, in verb types 16:20:16 we can also define models. Say for a Server, or for a DataObject 16:20:36 so instead of writing a Server class, we define it in a few lines of JSON 16:20:57 jamie_h i have a bunch of questions when you're ready 16:21:00 sure 16:21:59 jamie_h in your library you deal with validation. in your concepts how do you deal with the difference between testing and usage when it comes to validation? 16:22:36 can you elaborate what you mean by "testing" and "usage"? 16:22:49 do you mean how strict we'll be when using invalid schemas? 16:23:38 this isn't user submitted data. we don't need to spend the time validating it every time the SDK uses it. it's not going to change over time. can you skip validation in use and do it as part of the test suite? 16:24:00 i'm concerned with keeping things simple and code execution paths 16:24:12 that's a good idea. Right now, it doesn't skip validation - but it's something I can look it when incorporating into the SDK 16:24:33 when working with json schema files, how would you do debugging? 16:24:44 debugging errors with schemas? 16:25:00 that's one case 16:25:09 so right now you have a ErrorHandler which collects validation errors 16:25:12 to understand exactly what's going on and where. it's not in a line of code 16:25:29 what happens if it's not a validation issue 16:25:44 for example, the call goes through the proxy and the proxy changes things 16:25:57 now you need to know what's going on and where it's happening 16:26:32 There are two conceivable types of error: when a schema is itself invalid, or when a chunk of API data does not validate against a schema 16:26:51 Is that what you're referring to? I don't know what you mean by proxy changes 16:27:16 i'm thinking of the practical workflow of debugging. 16:27:34 the error handler collects the errors, and it's up to you how you want to handle them. right now they're buffered, and i collect them after the validation process over a foreach 16:27:41 when something normally encompassed in a method is now in a schema... what's that experience like? 16:27:42 alternatively, you can emit them over STDOUT 16:28:00 or save to a log file - it depends on how you implement ErrorHandlerInterface 16:28:21 that assumes the issue is a schema not validating. the schema could be proper and the requests could still fail 16:28:32 mfer when it comes to understanding normal SDK workflow debugging, I plead ignorance - I haven't got that far yet 16:28:44 ok. 16:28:51 If the request fails it indicates that the request data is invalid 16:28:57 in which case you'll get precise reasons why 16:29:02 given the time and the next meeting starting I think we need to take this offline. can we move this to an email? 16:29:08 okay 16:29:19 please cc the rest of us, I'm interested as well 16:29:19 jamie_h is there a BP + spec for this? 16:29:34 i'm sorry to interrupt. i'd love to talk about this for a long time. i'll try to send it out later today 16:29:44 https://blueprints.launchpad.net/openstack-sdk-php/+spec/service-json-schema 16:29:53 samchoi i'll send it to the openstack-dev list. but, i'll cc you too. make sure you're getting that list 16:30:05 #link https://blueprints.launchpad.net/openstack-sdk-php/+spec/service-json-schema 16:30:06 thanks jamie_h 16:30:16 ok, i'm calling the meeting so the next one can get started 16:30:19 thanks for coming 16:30:22 thanks 16:30:27 #endmeeting