| *** julim has quit IRC | 00:14 | |
| *** jcoufal has quit IRC | 00:29 | |
| *** amotoki has quit IRC | 00:30 | |
| *** cjellick has quit IRC | 00:32 | |
| *** troytoman is now known as troytoman-away | 00:41 | |
| *** dhellmann is now known as dhellmann_ | 00:43 | |
| *** troytoman-away is now known as troytoman | 00:50 | |
| *** troytoman is now known as troytoman-away | 00:55 | |
| *** MaxV has joined #openstack-meeting-3 | 00:57 | |
| *** cjellick has joined #openstack-meeting-3 | 01:02 | |
| *** MaxV has quit IRC | 01:02 | |
| *** jcoufal has joined #openstack-meeting-3 | 01:14 | |
| *** cjellick has quit IRC | 01:15 | |
| *** jcoufal has quit IRC | 01:15 | |
| *** devlaps has quit IRC | 02:01 | |
| *** yamahata has quit IRC | 02:36 | |
| *** amotoki has joined #openstack-meeting-3 | 02:58 | |
| *** yamahata has joined #openstack-meeting-3 | 03:22 | |
| *** annegentle has quit IRC | 03:42 | |
| *** wchrisj has quit IRC | 04:27 | |
| *** wchrisj has joined #openstack-meeting-3 | 04:36 | |
| *** MaxV has joined #openstack-meeting-3 | 05:08 | |
| *** MaxV has quit IRC | 05:12 | |
| *** wchrisj has quit IRC | 05:17 | |
| *** lpetrut has joined #openstack-meeting-3 | 05:48 | |
| *** tmazur has joined #openstack-meeting-3 | 05:51 | |
| *** mrunge has joined #openstack-meeting-3 | 06:41 | |
| *** saju_m has joined #openstack-meeting-3 | 07:12 | |
| *** MaxV has joined #openstack-meeting-3 | 07:21 | |
| *** MaxV has joined #openstack-meeting-3 | 07:22 | |
| *** lsmola has joined #openstack-meeting-3 | 07:23 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 07:28 | |
| *** MaxV has quit IRC | 07:31 | |
| *** MaxV has joined #openstack-meeting-3 | 07:38 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 07:47 | |
| *** amotoki has quit IRC | 07:47 | |
| *** MaxV has quit IRC | 07:57 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 08:25 | |
| *** saju_m has quit IRC | 08:26 | |
| *** MaxV has joined #openstack-meeting-3 | 08:49 | |
| *** lpetrut has quit IRC | 09:03 | |
| *** johnthetubaguy has joined #openstack-meeting-3 | 09:26 | |
| *** johnthetubaguy1 has joined #openstack-meeting-3 | 09:28 | |
| *** johnthetubaguy has quit IRC | 09:28 | |
| *** nacim has joined #openstack-meeting-3 | 09:28 | |
| *** saju_m has joined #openstack-meeting-3 | 09:42 | |
| *** lpetrut has joined #openstack-meeting-3 | 09:42 | |
| *** lpetrut has quit IRC | 09:55 | |
| *** lpetrut has joined #openstack-meeting-3 | 09:57 | |
| *** lpetrut has quit IRC | 10:14 | |
| *** yamahata has quit IRC | 10:18 | |
| *** ttrifonov has quit IRC | 10:30 | |
| *** ttrifonov has joined #openstack-meeting-3 | 10:31 | |
| *** ttrifonov has left #openstack-meeting-3 | 10:34 | |
| *** ttrifonov_zZzz has joined #openstack-meeting-3 | 10:38 | |
| *** ttrifonov_zZzz has left #openstack-meeting-3 | 10:39 | |
| *** ttrifonov_zZzz has joined #openstack-meeting-3 | 10:41 | |
| *** lpetrut has joined #openstack-meeting-3 | 10:42 | |
| *** ttrifonov_zZzz has joined #openstack-meeting-3 | 10:45 | |
| *** ttrifonov_zZzz has quit IRC | 10:47 | |
| *** ttrifonov_zZzz has joined #openstack-meeting-3 | 11:02 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 11:05 | |
| *** yamahata has joined #openstack-meeting-3 | 11:12 | |
| *** yamahata has quit IRC | 11:16 | |
| *** johnthetubaguy1 has quit IRC | 11:32 | |
| *** yamahata has joined #openstack-meeting-3 | 11:50 | |
| *** yamahata has quit IRC | 12:10 | |
| *** david-lyle has quit IRC | 12:39 | |
| *** saju_m has quit IRC | 12:40 | |
| *** mwagner_lap has quit IRC | 12:40 | |
| *** saju_m has joined #openstack-meeting-3 | 12:52 | |
| *** markmcclain has joined #openstack-meeting-3 | 13:03 | |
| *** saju_m has quit IRC | 13:04 | |
| *** dhellmann_ is now known as dhellmann | 13:11 | |
| *** lsmola has quit IRC | 13:23 | |
| *** markmcclain has quit IRC | 13:23 | |
| *** dhellmann is now known as dhellmann_ | 13:36 | |
| *** lsmola has joined #openstack-meeting-3 | 13:36 | |
| *** nacim_ has joined #openstack-meeting-3 | 13:43 | |
| *** nacim has quit IRC | 13:44 | |
| *** markmcclain has joined #openstack-meeting-3 | 13:48 | |
| *** wchrisj has joined #openstack-meeting-3 | 14:08 | |
| *** annegentle has joined #openstack-meeting-3 | 14:09 | |
| *** jpomero has quit IRC | 14:10 | |
| *** dguitarbite has joined #openstack-meeting-3 | 14:17 | |
| *** cgoncalves has quit IRC | 14:17 | |
| *** julim has joined #openstack-meeting-3 | 14:17 | |
| *** lsmola has quit IRC | 14:24 | |
| *** cgoncalves has joined #openstack-meeting-3 | 14:27 | |
| *** cgoncalves has joined #openstack-meeting-3 | 14:27 | |
| *** cgoncalves has quit IRC | 14:27 | |
| *** cgoncalves has joined #openstack-meeting-3 | 14:28 | |
| *** cgoncalves has joined #openstack-meeting-3 | 14:28 | |
| *** lblanchard has joined #openstack-meeting-3 | 14:30 | |
| *** lsmola has joined #openstack-meeting-3 | 14:33 | |
| *** lsmola has quit IRC | 14:33 | |
| *** lsmola has joined #openstack-meeting-3 | 14:34 | |
| *** mfer has joined #openstack-meeting-3 | 14:36 | |
| *** peristeri has joined #openstack-meeting-3 | 14:46 | |
| *** dguitarbite has quit IRC | 14:49 | |
| *** lsmola has quit IRC | 14:50 | |
| *** jnoller has joined #openstack-meeting-3 | 15:02 | |
| *** lcheng_ has joined #openstack-meeting-3 | 15:13 | |
| *** yamahata has joined #openstack-meeting-3 | 15:26 | |
| *** jpich has joined #openstack-meeting-3 | 15:27 | |
| *** david-lyle has joined #openstack-meeting-3 | 15:28 | |
| *** lsmola has joined #openstack-meeting-3 | 15:32 | |
| *** lcheng_ has quit IRC | 15:35 | |
| *** coolsvap has joined #openstack-meeting-3 | 15:38 | |
| *** lcheng_ has joined #openstack-meeting-3 | 15:44 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 15:46 | |
| *** mrunge has quit IRC | 15:47 | |
| *** markmcclain has quit IRC | 15:47 | |
| *** jpomero has joined #openstack-meeting-3 | 15:49 | |
| *** mrunge has joined #openstack-meeting-3 | 15:49 | |
| *** devlaps has joined #openstack-meeting-3 | 15:50 | |
| *** mrunge has quit IRC | 15:50 | |
| *** johnthetubaguy has joined #openstack-meeting-3 | 15:54 | |
| *** johnthetubaguy1 has joined #openstack-meeting-3 | 15:57 | |
| *** coolsvap1 has joined #openstack-meeting-3 | 15:58 | |
| *** johnthetubaguy has quit IRC | 15:58 | |
| *** mrunge has joined #openstack-meeting-3 | 16:00 | |
| *** pbelanyi has joined #openstack-meeting-3 | 16:00 | |
| *** coolsvap has quit IRC | 16:00 | |
| david-lyle | #startmeeting Horizon | 16:01 |
|---|---|---|
| openstack | Meeting started Tue Mar 4 16:01:26 2014 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| *** openstack changes topic to " (Meeting topic: Horizon)" | 16:01 | |
| openstack | The meeting name has been set to 'horizon' | 16:01 |
| *** akrivoka has joined #openstack-meeting-3 | 16:01 | |
| david-lyle | Hello everyone | 16:01 |
| lsmola | hello | 16:01 |
| mrunge | o/ | 16:01 |
| akrivoka | hello \o | 16:01 |
| lcheng_ | hello | 16:01 |
| tmazur | hello o/ | 16:01 |
| *** doug-fish1 has joined #openstack-meeting-3 | 16:02 | |
| jpich | Hi | 16:02 |
| lblanchard | hi all | 16:02 |
| doug-fish1 | greetings! | 16:02 |
| jpomero | hi | 16:02 |
| david-lyle | The final day for features and strings in Icehouse is upon us | 16:02 |
| david-lyle | https://launchpad.net/horizon/+milestone/icehouse-3 | 16:02 |
| david-lyle | 1 Blocked, 17 Needs Code Review, 22 Implemented | 16:02 |
| david-lyle | The top two in the list are FFE material | 16:03 |
| jomara | hi | 16:03 |
| david-lyle | 2-3 were approved and had merge conflicts | 16:03 |
| david-lyle | and some need reviews or more work | 16:03 |
| david-lyle | if we can clearly identify the items we think need more work and should be pushed to Juno, it would simplify the rest of the day :) | 16:04 |
| *** absubram has joined #openstack-meeting-3 | 16:04 | |
| mrunge | david-lyle, te | 16:04 |
| mrunge | david-lyle, the separation of horizon and dashboard is one thing for juno | 16:05 |
| jpich | IMO at this stage, if the "more work" is a nice to have, or smaller bugs that can be handled before RC (e.g. small performance improvements, docs, etc) it's ok to +2 and open a new bug for the extra work | 16:05 |
| jomara | david-lyle: ive had some reviews get approved but out of order (ie, a string of dependent patches), so there are merge conflicts that wont resolve until the dependency chain is reviewed | 16:05 |
| david-lyle | jomara, I think the ones not approved have -1's on them | 16:07 |
| jomara | do they?? i will double check, from my dashboard they appeared green butr maybe that is misleading | 16:07 |
| david-lyle | we can discuss it those are enough to block the change and be fixed in the RC | 16:07 |
| jpich | a +2 can hide -1s | 16:08 |
| jomara | david-lyle: oh boy, it looks like if someone +2s, the -1 doesnt show up on from the front view | 16:08 |
| jomara | yeah.. dang | 16:08 |
| david-lyle | jomara: https://review.openstack.org/#/c/73433/ is just a merge conflict as well | 16:08 |
| jpich | :( IIRC some of them could easily be done after FF and before the RC, e.g. fixing up docstrings | 16:08 |
| david-lyle | no dependency | 16:08 |
| david-lyle | I would be fine with that | 16:09 |
| lcheng_ | jomara: seems like the bottleneck is here: https://review.openstack.org/#/c/71395/4 | 16:09 |
| david-lyle | Lot's of good work to block on a doc string | 16:09 |
| lcheng_ | Got approved but it was not merged, I'll approve it again to trigger the build. | 16:09 |
| jomara | lcheng_: ah, thanks | 16:09 |
| jomara | ok, ill try to get everything fixed up ASAP | 16:10 |
| jomara | sorry about that, i didnt realize i wasnt seeing the -1s | 16:10 |
| jpich | lcheng_: The review it depends on isn't merged though, I don't think it'll go through yet | 16:10 |
| david-lyle | I think jpich is correct | 16:10 |
| *** devlaps has quit IRC | 16:11 | |
| lcheng_ | jpich: you're right | 16:11 |
| lcheng_ | https://review.openstack.org/#/c/66603/19 | 16:11 |
| jomara | david-lyle: the one you linked is also dependent, but it says its a merge conflict, i assumed it was due to earlier patches | 16:11 |
| *** devlaps has joined #openstack-meeting-3 | 16:11 | |
| david-lyle | ok, just not a dependency according to gerrit | 16:12 |
| lcheng_ | jomara: I think this is the top of the chain https://review.openstack.org/#/c/66603/19 | 16:12 |
| *** dhellmann_ is now known as dhellmann | 16:12 | |
| jomara | lcheng_: yes, that should be | 16:12 |
| jomara | lcheng_: it has 2 -1s that were hidden by the +2 | 16:13 |
| jomara | so ill start there and owrk my way down | 16:13 |
| david-lyle | as a heads up https://blueprints.launchpad.net/horizon/+spec/django-1point6 is blocked by an openstack/requirements approval | 16:14 |
| *** markmcclain has joined #openstack-meeting-3 | 16:15 | |
| david-lyle | once that happens, I going to update and release django_openstack_auth and the update Horizon to have a tox env for 1.5 and 1.6 | 16:15 |
| jpich | david-lyle: Will adding a django15 job be done separately or is there a related patch already? | 16:15 |
| jpich | Sounds good | 16:15 |
| david-lyle | in openstack_auth, it will happen in one patch, in Horizon I will update the requirements and add the tox job in the same patch | 16:15 |
| lcheng_ | jomara: thanks, me and david-lyle are in the US. We can follow-up on the heat patches for the rest of the day. | 16:16 |
| david-lyle | depending on who's awake, I may just push the changes through | 16:16 |
| jomara | lcheng_: awesome, thanks | 16:16 |
| david-lyle | It's really just book keeping at that point | 16:16 |
| david-lyle | also looks like https://review.openstack.org/#/c/61032/ is a priority for Hyper-V support | 16:19 |
| david-lyle | it wasn't targeted until yesterday | 16:20 |
| david-lyle | So after icehouse-3 is tagged, master will still be icehouse until RC1 is but in a few weeks | 16:21 |
| david-lyle | then the items left over can start merging to Juno | 16:21 |
| david-lyle | #topic Open Discussion | 16:23 |
| *** openstack changes topic to "Open Discussion (Meeting topic: Horizon)" | 16:23 | |
| david-lyle | I think we were there, but now it's official :) | 16:23 |
| lblanchard | I worked with sayalilunkad last week to put together a design for Sparklines on the instance table. We are hoping to hear from lsmola on his thoughts on direction for her to go in…here is the design: http://people.redhat.com/~lsurette/OpenStack/Sparklines%20on%20Instance%20Table | 16:24 |
| *** cjellick has joined #openstack-meeting-3 | 16:24 | |
| david-lyle | you know, that table could really use more columns ;) | 16:25 |
| lblanchard | haha | 16:25 |
| lsmola | lblanchard: great | 16:25 |
| lblanchard | might push us towards a "Add/Remove Columns" feature :) | 16:25 |
| akrivoka | lblanchard: nice! | 16:25 |
| lsmola | lblanchard: sayali is investigating whether the meters are good for this | 16:25 |
| lblanchard | but the thoughts is that RAM and vCPU would be two very nice metrics to show here for each instance | 16:25 |
| lblanchard | lsmola: great! | 16:25 |
| jpich | Maybe we should move the actions toward the beginning of the table at some point, to avoid having to scroll to do stuff | 16:26 |
| david-lyle | I do like the look of it, very clean | 16:26 |
| lblanchard | and also…adding two sparklines to the instance table would be a nice attainable goal before her internship ends on the 10th :) | 16:26 |
| david-lyle | 10th of? | 16:26 |
| lblanchard | david-lyle: march | 16:26 |
| david-lyle | :( | 16:26 |
| lblanchard | david-lyle: yeah :( | 16:26 |
| lblanchard | jpich: great point | 16:26 |
| *** absubram has quit IRC | 16:27 | |
| *** johnthetubaguy1 is now known as johnthetubaguy | 16:27 | |
| david-lyle | or perhaps a different way to render colums | 16:27 |
| david-lyle | columns | 16:27 |
| lblanchard | david-lyle: yes for sure | 16:27 |
| lblanchard | one thing to ask too is…are all of these columns necessary here | 16:27 |
| lblanchard | or would some be okay to drop to the details view | 16:27 |
| david-lyle | put state information in the same column but in multiple rows, sparklines in the same column, etc | 16:28 |
| lblanchard | david-lyle: right, we can definitely merge and reformat some of these values | 16:28 |
| lblanchard | I will brainstorm an idea for next week | 16:28 |
| david-lyle | but for now and as dar as sayali is concerned, the layout you have proposed looks like a great way to move forward and have a tangable endpoint | 16:29 |
| david-lyle | s/dar/far/ | 16:29 |
| lsmola | lblanchard: great | 16:29 |
| lblanchard | great, thanks! | 16:29 |
| lblanchard | lsmola: will you follow up with her when she comes online? I know she was looking to hear from you on this to confirm. | 16:30 |
| lsmola | lblanchard: we have talked today | 16:30 |
| jpich | I'd love to get some attention on the host aggregates patch if some of the cores have a chance to take a look. I reviewed it a few times, not sure if it's ok to leave a final +2 since I made the last change (a couple of tests) -> https://review.openstack.org/#/c/71061/ . It'd be neat to have in Icehouse :) | 16:30 |
| lblanchard | lsmola: perfect | 16:30 |
| lsmola | lblanchard: she just need to make sure the meters gives us correct data and this can be done | 16:31 |
| lblanchard | lsmola: sounds great, I'll hope they fit in :) | 16:31 |
| david-lyle | jpich, just rebasing, I would say it's fine to +2 | 16:32 |
| *** absubram has joined #openstack-meeting-3 | 16:32 | |
| jpich | david-lyle: I added a couple of tests as well | 16:32 |
| jpich | :O | 16:32 |
| david-lyle | well, that's just bonus points :) | 16:33 |
| cgoncalves | hi all. I've a question regarding a blueprint I'm currently working on (https://blueprints.launchpad.net/horizon/+spec/download-images-and-snapshots). project dashboard implementation is ready and I'm currently addressing finishing adding support on the admin dashboard as requested in review.o.o which should be ready today. only UT missing as requested by mrunge. any chance of approving this for I-3 or is it too late now? | 16:33 |
| jpich | heh :) | 16:33 |
| jpich | cgoncalves: It really help to set the milestone target when working on a blueprint so it can be considered during release tracking | 16:35 |
| julim | lblanchard david-lyle -- in looking at the instance table, if we can drop some of the columns (and put them in details) that would be great, e.g. why do we need to include image name, size, key pair, ip address | 16:35 |
| jpich | otherwise especially when approaching the end of a milestone it's unlikely to get as much review attention | 16:36 |
| cgoncalves | jpich: I did set it, but david-lyle removed it very recently (today morning I think) | 16:36 |
| julim | <sorry… late joining the meeting> | 16:36 |
| david-lyle | cgoncalves, I did, I went through the bps targeted for icehouse and items that had not received much attention or looked like they had work left (adding tests) were moved out | 16:37 |
| absubram | side Q sorry.. how do you set the milestone? I've never been able to edit that field.. bugs or bp | 16:37 |
| lblanchard | julim: yes, I'm wondering something similar…what is important to see at this table level and what could be put into a details view. Perhaps we could do some user testing here to make sure we make informed changes. | 16:38 |
| jpich | absubram: The assignee should be able to set the target on a blueprint, IIUC | 16:38 |
| julim | sounds good lblanchard. | 16:38 |
| absubram | jpich: thanks.. I'll keep an eye on it next time I open a bp :) | 16:39 |
| cgoncalves | david-lyle: I didn't look yet for how to implement a UT for testing the correctness of downloading an image from horizon in client-side. in case it's feasible and somehow trivial, I should implement it in time | 16:40 |
| cgoncalves | david-lyle: the request for such UT was only asked a couple hours ago. I've been addressing all comments on review.o.o as fast as I can as you can see (https://review.openstack.org/#/c/74799/) | 16:41 |
| jpich | absubram: Ok! It's part of the steps for creating a blueprint so please say something if that's not actually possible ( https://wiki.openstack.org/wiki/Blueprints#Creation ) | 16:41 |
| david-lyle | cgoncalves, I'll look at it again a client side download test may not make sense in unit tests | 16:42 |
| cgoncalves | david-lyle: thanks. that was what I understood from mrunge's comment, a client side download test. | 16:42 |
| absubram | jpich: thanks for the link! | 16:43 |
| jpich | absubram: I am a link factory, at your service :) | 16:43 |
| david-lyle | jpich, they show up targeted all the time, so I hope someone is setting it :) | 16:43 |
| jpich | Maybe someone wrote a prediction bot to save people's time | 16:44 |
| absubram | david-lyle: haha yes.. I've only opened on bp myself (in grizzly!).. it's normally bugs that I open and that's more of what I was thinking of | 16:44 |
| absubram | one* | 16:45 |
| absubram | jpich: haha.. that'd be a nice bot to have! | 16:45 |
| mrunge | ah no, I was just for something more checking than just watching if the menu item was added cgoncalves | 16:47 |
| absubram | david-lyle: about my bp - https://blueprints.launchpad.net/horizon/+spec/neutron-subnet-mode-support… neutron side is still sitting on -1 review :(.. am tracking it daily.. I think amotoki is also a reviewer there | 16:48 |
| absubram | will send you a note to let you know if they somehow get their code in | 16:48 |
| david-lyle | absubram, thanks for the update, I have that bp slated as a possible FFE, may be on the neutron side too, not sure | 16:49 |
| david-lyle | keep me posted | 16:49 |
| absubram | will do | 16:49 |
| absubram | I had a comment in my review about the edit subnet portion not working (wanted to talk to amotoki about that since he also has a comment in that piece of code) | 16:50 |
| absubram | but its looking like neutron might not support edit in i.. only in J | 16:50 |
| absubram | so even if we got our Horizon support in.. it would only be to add the two new ipv6 attributes during subnet create | 16:50 |
| cgoncalves | mrunge: ok, thanks for your input here! do you happen to have a concrete idea of how that should be tested? any pointers? :-) | 16:50 |
| absubram | we would have to fix update subnet in J | 16:51 |
| mrunge | cgoncalves, look at the other tests, like launching machines, creating volumes... | 16:51 |
| cgoncalves | mrunge: ok, will do. | 16:52 |
| mrunge | cgoncalves, and if there's anything, feel free to drop me a note | 16:52 |
| cgoncalves | mrunge: sure. thanks once again! | 16:53 |
| absubram | on a separate note though.. I have a bunch of minor bug fix patches out in review and looking for reviewers :p.. I know everyone's trying to get the BP's in.. so whenever people get a chance.. (amotoki hehe) | 16:54 |
| david-lyle | bugs will take a much higher priority after today | 16:55 |
| jpich | bug fixes can be merged in till the RC, I think people will focus on these more once feature freeze has passed | 16:55 |
| jpich | yeah | 16:55 |
| jpich | stabilisation FTW | 16:55 |
| mrunge | oh yes! | 16:55 |
| absubram | yep.. figured so.. it's fine :) thanks | 16:55 |
| mrunge | I can only encourage folks to install different environments to test! | 16:55 |
| absubram | if we have time for open Qs.. I did have a question about one particular unit test that's giving me a little trouble on a separate issue.. the launch_instance_post | 16:57 |
| absubram | if not I can send out an email to the mailer | 16:57 |
| *** MaxV has quit IRC | 16:58 | |
| david-lyle | absubram, just post it in the regular room | 16:58 |
| david-lyle | I don't think we have time here | 16:58 |
| absubram | cool.. will do | 16:59 |
| absubram | that's fine :) | 16:59 |
| david-lyle | I'd like to thank everyone for the review efforts, core and non-core. We've merged a lot of great work in icehouse and have a lot more ready for Juno. If your bp doesn't make it into icehouse, I will target it for Juno as soon as it opens up. I think the release cycle is just here to add a huge amount of stress every 6 months. And, I suppose to keep us honest :) Thanks everyone. | 16:59 |
| david-lyle | Have a great week! | 17:00 |
| david-lyle | #endmeeting | 17:00 |
| *** openstack changes topic to "Free for all (Meeting topic: Horizon)" | 17:00 | |
| openstack | Meeting ended Tue Mar 4 17:00:30 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| jpich | You too, thanks everyone | 17:00 |
| absubram | thank you | 17:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-03-04-16.01.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-03-04-16.01.txt | 17:00 |
| mrunge | thank you david-lyle | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-03-04-16.01.log.html | 17:00 |
| *** doug-fish1 has left #openstack-meeting-3 | 17:00 | |
| *** mrunge has quit IRC | 17:00 | |
| *** absubram has quit IRC | 17:01 | |
| *** pbelanyi has left #openstack-meeting-3 | 17:02 | |
| lsmola | thank you, have a great week | 17:02 |
| tmazur | thank you! | 17:02 |
| *** tmazur has quit IRC | 17:03 | |
| *** akrivoka has left #openstack-meeting-3 | 17:06 | |
| *** jcoufal has joined #openstack-meeting-3 | 17:16 | |
| *** muralia1 has joined #openstack-meeting-3 | 17:32 | |
| *** muralia1 has quit IRC | 17:44 | |
| *** troytoman-away is now known as troytoman | 17:44 | |
| *** mwagner_lap has joined #openstack-meeting-3 | 17:49 | |
| *** jcoufal_ has joined #openstack-meeting-3 | 18:02 | |
| *** jcoufal has quit IRC | 18:05 | |
| *** lpetrut has quit IRC | 18:05 | |
| *** lpetrut has joined #openstack-meeting-3 | 18:06 | |
| *** yamahata__ has joined #openstack-meeting-3 | 18:10 | |
| *** lpetrut has quit IRC | 18:13 | |
| *** yamahata has quit IRC | 18:14 | |
| *** lpetrut has joined #openstack-meeting-3 | 18:33 | |
| *** nacim_ has quit IRC | 18:40 | |
| *** johnthetubaguy has quit IRC | 18:51 | |
| *** jpomero has quit IRC | 18:57 | |
| *** briancurtin has joined #openstack-meeting-3 | 18:59 | |
| *** jamielennox has joined #openstack-meeting-3 | 19:00 | |
| *** bknudson has joined #openstack-meeting-3 | 19:00 | |
| briancurtin | #startmeeting python-openstacksdk | 19:00 |
| openstack | Meeting started Tue Mar 4 19:00:22 2014 UTC and is due to finish in 60 minutes. The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot. | 19:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 19:00 |
| *** openstack changes topic to " (Meeting topic: python-openstacksdk)" | 19:00 | |
| openstack | The meeting name has been set to 'python_openstacksdk' | 19:00 |
| briancurtin | #link agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-03-04_1900_UTC | 19:01 |
| briancurtin | Can everyone here for the Python OpenStack SDK meeting state their name and affiliation? | 19:01 |
| jnoller | Jesse Noller, Rackspace | 19:01 |
| mfer | Matt Farina, HP | 19:01 |
| bknudson | Brant Knudson, IBM | 19:02 |
| briancurtin | Brian Curtin, Rackspace | 19:02 |
| wchrisj | Chris Johnson, HP | 19:02 |
| edleafe | Ed Leafe, Rackspace | 19:02 |
| jamielennox | Jamie Lennox, Red Hat | 19:02 |
| *** dtroyer has joined #openstack-meeting-3 | 19:02 | |
| jnoller | dtroyer: we're in the name & affiliation roll call | 19:03 |
| *** jpomero has joined #openstack-meeting-3 | 19:03 | |
| dtroyer | ok…Dean Troyer, Nebula | 19:03 |
| briancurtin | i think we're probably set to go, people may just roll in late | 19:04 |
| briancurtin | # topic Feedback on the wiki / current state (open discussion) | 19:04 |
| briancurtin | #topic Feedback on the wiki / current state (open discussion) | 19:04 |
| *** openstack changes topic to "Feedback on the wiki / current state (open discussion) (Meeting topic: python-openstacksdk)" | 19:04 | |
| jnoller | #link https://wiki.openstack.org/wiki/PythonOpenStackSDK | 19:04 |
| briancurtin | fwiw, i have some wiki stuff to talk about with extensions but it falls explicitly under that topic. the wiki is mostly unchanged since the last meeting outside of that, though | 19:05 |
| jnoller | Does anyone have anything to discuss - have people taken a look at the blueprints / etc | 19:06 |
| jamielennox | has there been any change in the project since last meeting? | 19:06 |
| jamielennox | i haven't seen anything for blueprint/wiki aspect | 19:06 |
| bknudson | is there any code or a repo? | 19:06 |
| jnoller | jamielennox: Brian and others have been working on blueprints primarily | 19:06 |
| briancurtin | jamielennox: perhaps we should discuss your comment on the implement-services blueprint? "I'm still interested in the ability of taking the API version specific core of the various clients and keeping SDK focused on the problem of abstracting that information. It does not affect that we will need to implement bindings to the services though." | 19:07 |
| edleafe | bknudson: no - we're still discussing design requirements/ideas | 19:07 |
| briancurtin | jamielennox: other than that, there's some vendor/third-party extension stuff to discuss that we could jump into | 19:07 |
| jnoller | Actually, could you clarify that jamielennox? | 19:08 |
| jamielennox | briancurtin: sure, it's essentially the same concern i've had previously in the goal of the SDK | 19:08 |
| jamielennox | is the goal to provide a replacement for all the clients | 19:08 |
| jamielennox | or a more sane way to deal with them all and do cross api versions nicely | 19:08 |
| bknudson | looks like a requirement of this project is to not use the existing clients. | 19:09 |
| jamielennox | my concern with point a is the duplication of effort | 19:09 |
| jamielennox | So the blueprint i put up was to start a discussion about how we do cross API versions nicely | 19:09 |
| *** sivel has joined #openstack-meeting-3 | 19:09 | |
| edleafe | jamielennox: The existing clients are not very consistent | 19:09 |
| jamielennox | i'm particularly coming from keystone here where the change from v2 to v3 is a significant API break | 19:10 |
| jamielennox | edleafe: i completely agree | 19:10 |
| mfer | I'm not sure there is a way to take the existing client code and have it fit into the requirements | 19:10 |
| jnoller | I would say that re-using code from them is good; but the individual clients that we expose as API endpoints to the users needs more consistency: I think the new keystone client is actually a good starting point as an effort for a common backend | 19:11 |
| edleafe | mfer: Exactly. There are some good design pieces, but not whole clients | 19:11 |
| jamielennox | i have been trying to do cross client work recently and i completely agree - but does that mean we start again or try to fix them | 19:11 |
| bknudson | jamielennox: were you planning to have other clients import keystoneclient? | 19:11 |
| jnoller | Well, there's the other effort under oslo working on code reuse / etc - but I think that we have to actually start from 0 and look at what works and doesn't work - e.g. the keystone changes | 19:12 |
| mfer | if the existing clients can't meet the needs than I don't see another way than to re-implement it. | 19:12 |
| jamielennox | this is a lot of what andrey is pushing with the common apiclient | 19:12 |
| edleafe | jamielennox: in my experience, starting with a good overall design will make adding binding for each additional service that much easier | 19:12 |
| dtroyer | I think starting fresh rather than trying to do it in-place is a win because we don't have to worry about backward-compatability | 19:12 |
| jnoller | dtroyer++ | 19:12 |
| briancurtin | yep | 19:12 |
| mfer | dtroyer++ | 19:12 |
| jamielennox | bknudson: not if the session code works out how i would like | 19:12 |
| wchrisj | dtroyer++ | 19:12 |
| jamielennox | dtroyer: ok | 19:12 |
| jnoller | but I think we *need* to look at what the clients do right jamielennox | 19:13 |
| mfer | we aren't trying to build the next rev for the openstack devs. we're trying to build the first rev for application devs. | 19:13 |
| jnoller | mfer: well put | 19:13 |
| edleafe | mfer: exactly | 19:14 |
| dtroyer | mfer: but if it happens to be too good for the openstack devs to pass up, well, win? | 19:14 |
| jamielennox | mfer: yes, so long as that is not to the exclusion of the devs | 19:14 |
| jamielennox | (not implying it will) | 19:14 |
| jnoller | We have to bring both along for the ride; | 19:14 |
| jnoller | but remember the key audience | 19:14 |
| mfer | jamielennox i think it's more about keeping the target in focus so we shoot for a clear goal that try to be all things to all people | 19:14 |
| bknudson | there might be something that devs would like. e.g. they're using it to test their REST API. We don't need to support that. | 19:14 |
| edleafe | we are building a clean, usable python SDK for python developers | 19:15 |
| briancurtin | for end-users | 19:15 |
| jamielennox | ok - didn't mean to sidetrack this again | 19:15 |
| jnoller | jamielennox: no man, good question | 19:15 |
| bknudson | I think some people were thinking we'd have the API automatically generated. | 19:16 |
| jamielennox | the blueprint i posted was particularly about how to deal with the cross API versions and distinguishing what is and is not available on a specific api | 19:16 |
| bknudson | maybe from the schema for the services. | 19:16 |
| jnoller | jamielennox: and I think its fair (and we have to check our assumptions) | 19:16 |
| jamielennox | (i assume that's where the quote came from) | 19:16 |
| bknudson | but I wouldn't expect that would lead to the user API we'd like. | 19:16 |
| jnoller | bknudson: I don't think auto-generated code lends itself to sanity | 19:16 |
| wchrisj | jnoller++ | 19:17 |
| dtroyer | plus, it'll be a while before that is even available to us for more than 1 or 2 APIs | 19:17 |
| jnoller | Yeah, using jsonschema would be awesome, but I *personally* distrust exposing auto-generated code to end-users. | 19:18 |
| dolphm | (jumping in late) everyone keeps talking about the "target audience" etc, but it's not clear what segment of developer/users that actually is | 19:18 |
| mfer | jnoller is there much in the form of jsonschema right now? | 19:18 |
| wchrisj | I like the idea of using that sort of tool to help us as devs keep things up to date tho... | 19:18 |
| jnoller | dolphm: from https://wiki.openstack.org/wiki/PythonOpenStackSDK - "application developer consumers" | 19:19 |
| dolphm | some APIs are aimed at deployers / cloud administrators - are we targeting them? | 19:19 |
| bknudson | the nova v3 api has validation through a schema. | 19:19 |
| briancurtin | mfer: marconi has some usage of jsonschema from what i remember | 19:19 |
| edleafe | dolphm: python developers building apps that use OpenStack services | 19:19 |
| mfer | I saw a small amount of json schema in glance. but, not a whole lot all around | 19:19 |
| jnoller | dolphm: I think we discussed some of that last time: the main abstraction wouldn't leak those deployer / admin tools, but there's no reason why the underlying client code would not (essentially a leaky abstraction) | 19:20 |
| jnoller | dolphm: Also, I think we totally have room for a OpenStackClient / OpenStackAdmin style set of objects | 19:20 |
| bknudson | so I think this is where jamielennox's comment about duplication of effort comes in -- | 19:20 |
| bknudson | we're going to have the appllication developer API, but we'll still need the other python-* APIs around | 19:20 |
| jamielennox | jnoller: i don't see why it can't include admin functionality. probably one of the main people who will want to script these services are the cloud admins | 19:21 |
| jnoller | bknudson: Not if we implement those to | 19:21 |
| edleafe | bknudson: not sure why that follows | 19:21 |
| dolphm | so, the long term goal is to support every API exposed by every service, not just a specific subset | 19:21 |
| jnoller | jamielennox: Yeah, I'm just saying name them explicitly | 19:21 |
| dtroyer | If the SDK has basically two layers we can address both needs: the low-level that is API version-specific and an abstraction over that (like jamielennox talked about) to hide the messiness | 19:21 |
| edleafe | you can build tools on the SDK that are targeted for different use cases | 19:21 |
| jamielennox | dtroyer: ++ | 19:21 |
| edleafe | the SDK simply wraps the low-level API in a Pythonic way | 19:21 |
| bknudson | so for example an application developer API isn't the cloud management API ... | 19:21 |
| briancurtin | bknudson: eventually, those python-* APIs can use this SDK as a backend. over time, end-users could move off of those python-* APIs into using the highest level abstractions the SDK provides | 19:21 |
| bknudson | and Horizon is going to use the management API | 19:21 |
| jamielennox | briancurtin: that's... ambitious | 19:22 |
| jnoller | dolphm: In the internals - yes, for example, openstacksdk.services.keystone could be rich and support all of the APIs; but developers would not start there, they'd use, say, openstacksdk.client which would expose a clean and consistent subset | 19:22 |
| edleafe | clarification: when we say "APIs", are we talking about "CLIs"? | 19:22 |
| dolphm | briancurtin: what's the benefit of that dependency relationship? | 19:22 |
| bknudson | I'm willing to put up with the code duplication since it's different uses. | 19:22 |
| dtroyer | edleafe: no | 19:22 |
| dolphm | edleafe: i hope not | 19:22 |
| briancurtin | edleafe: a CLI is an application of an API | 19:22 |
| edleafe | That's my understanding | 19:23 |
| jamielennox | CLIs should come nowhere near this project | 19:23 |
| bknudson | but it also looks like, if we do have duplication, some of this could be shared... e.g., "Verified mocks/stubs for testing at all layers. " | 19:23 |
| dolphm | jamielennox: ++ | 19:23 |
| wchrisj | The CLI would use the SDK we are discussing | 19:23 |
| edleafe | But it sounds like the two are being confused | 19:23 |
| dolphm | if this thing has a CLI beyond python -c then i'm going to cry | 19:23 |
| *** Alex_Gaynor has joined #openstack-meeting-3 | 19:23 | |
| wchrisj | no CLI here | 19:23 |
| jnoller | jamielennox: That was in the spec / wiki page: ideally the python-* clients could leverage a single dependency (this SDK) | 19:23 |
| dtroyer | But there is one next door that cares deeply about this project ;) | 19:23 |
| edleafe | Then explain what the issue is with apps that would be used for deployment vs. other uses | 19:24 |
| edleafe | The API is the API, and the SDK simply wraps that | 19:24 |
| briancurtin | dolphm: to get to your earlier question about the benefit of the dependency, is that it gets each client away from writing their own HTTP stack, their own everything | 19:24 |
| jamielennox | jnoller: i think the dependency there is a bit backwards - but it works if your goal is deprecation of the python-*clients | 19:24 |
| edleafe | There isn't any other functionality being added, is there? | 19:24 |
| jnoller | jamielennox: Mine is. | 19:24 |
| dtroyer | edleafe: I think the distinction is client needs within OpenStack itself (auth_token for example) vs external | 19:24 |
| mfer | Services expose APIs, the SDK wraps them, CLIs and other applications wrap the SDK | 19:24 |
| jamielennox | jnoller: i think the compatibility will still kill it | 19:24 |
| jnoller | jamielennox: Time will answer that; sort of like the V3 discussions | 19:25 |
| edleafe | mfer: exactly. So what's the confusion about devops vs. app devs? | 19:25 |
| edleafe | They would use tools built for their needs on top of the SDK | 19:25 |
| mfer | edleafe if a dev ops person wants to write an application that helps with ops they can use the SDK. it's the development part rather than the ops part. Ops part uses tools build on top of the SDK | 19:26 |
| edleafe | That's my view, too | 19:26 |
| mfer | the dev in devlops is the target of the SDK not the ops part of devops | 19:26 |
| dolphm | there also seems to be some confusion around the term "SDK" -- it's a "client library for openstack as a whole" first and foremost, as i understand it | 19:26 |
| jnoller | dolphm / jamielennox - is there an action item for us to to clarify this | 19:27 |
| mfer | dolphm it's an SDK. A CLI or other application is a different project | 19:27 |
| jnoller | An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes: | 19:27 |
| jnoller | Documentation aimed at users consuming the SDK and system. | 19:27 |
| jnoller | Clear examples of usage, including functioning, executable examples. | 19:27 |
| edleafe | dolphm: SDK == language binding + docs + examples, etc. | 19:27 |
| dolphm | edleafe: agree | 19:27 |
| dolphm | jnoller: i'm asking questions for my own benefit, mostly | 19:27 |
| jamielennox | jnoller: i was just looking for are we looking to replace existing clients | 19:27 |
| mfer | so, my burning question is... what do we want to get done by the next meeting? | 19:27 |
| jnoller | OK | 19:27 |
| jamielennox | indeed, moving on | 19:28 |
| jnoller | mfer: We do have the vendor extensions thing brian drafted | 19:28 |
| * mfer wants code to be written and magic to be made | 19:28 | |
| briancurtin | shall we move on to that? | 19:28 |
| jnoller | yes please | 19:28 |
| briancurtin | #topic https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK/Extensions | 19:28 |
| *** openstack changes topic to "https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK/Extensions (Meeting topic: python-openstacksdk)" | 19:28 | |
| briancurtin | that's just a bunch of ideas and directions throw out on paper - not written to go any one way, just to put things on the table | 19:28 |
| briancurtin | a lot of it is pulled from previous meeting and previous talks | 19:29 |
| jnoller | Clarification: This intentionally avoids setup tools entrypoints | 19:29 |
| jamielennox | ++ on explicit importing | 19:30 |
| jamielennox | i think whether extensions are vendor or service orientated will depend on the structure we come up with for the core | 19:30 |
| jnoller | Does anyone have strong feelings here: ideally vendor extensions go the way of the dodo however, since say rackspace and HP have CDN, we could collaborate on a openstack.extensions.cdn extension | 19:31 |
| jamielennox | but both would be nice | 19:31 |
| jnoller | yeah | 19:31 |
| edleafe | I think there will always be vendor extensions, as much as we'd wish for them to not be needed | 19:31 |
| jnoller | (also, love "CloudVendor Cloud" - modifying summit talk slides) | 19:31 |
| Alex_Gaynor | I'm -1 on vendor extensions in the main repo. | 19:32 |
| jamielennox | jnoller: -- on the setuptools thing though, i realize it's ugly but let's just wrap it behind stevedore and let the setuptools fixes come as they will | 19:32 |
| wchrisj | Only concern on my part with external is possibility of degraded quality (inadequate test enforcement) | 19:32 |
| jnoller | jamielennox: That prevents single binary builds, and consistently causes random installation problems | 19:32 |
| dtroyer | do we have to call it 'vendor extensions?' is there a functional disctinction from, say, an extension to support a not-yet-incubated API? | 19:32 |
| Alex_Gaynor | If we were to have vendor extensions, how would we even decide what vendors? | 19:32 |
| jnoller | Alex_Gaynor: Allow them to commit to the repo | 19:32 |
| jamielennox | wchrisj: i think that's the cost you pay for being outside the core and it will hurt those vendors who develop externally | 19:32 |
| briancurtin | Alex_Gaynor: whichever vendors want to provide their extensions | 19:33 |
| dolphm | i'd rather not have vendor-specific code in-tree, period | 19:33 |
| Alex_Gaynor | jnoller: who, anybody? | 19:33 |
| Alex_Gaynor | If I run a server in my apartment am I allowed to put my vendor extensions in here? | 19:33 |
| jnoller | Alex_Gaynor: If there is an external vendor thing, for say rackspace, I expect a PR from rackspace exposing it | 19:33 |
| mfer | when i think of this I'm thinking of the end users again. The app developer may want to write an app to connect to an IBM private cloud, an HP managed cloud, and a Rackspace public cloud. Now we want to enable them to do that with as little pain as possible | 19:33 |
| Alex_Gaynor | What's the procedure for testing these things in the gate? | 19:33 |
| jamielennox | jnoller: is single binary builds a concern? | 19:33 |
| briancurtin | Alex_Gaynor: that's where the internal thing gets complicated, in that there probably has to be some graduation process, third-party testing, etc | 19:33 |
| jnoller | jamielennox: Yes | 19:33 |
| briancurtin | absolutely | 19:33 |
| dtroyer | jamielennox: that's a big reason why entrypoints need to go away | 19:34 |
| briancurtin | mfer: that problem is important, is somewhat addressed by both where the code lives, and how it's distributed (and maybe a combination of both) | 19:34 |
| jnoller | relying on setuptools to manage extensions is not a win unless you can guarantee the installation environment | 19:34 |
| jamielennox | is this a windows thing? (out of interest - not because of redhat) | 19:35 |
| *** lsmola has quit IRC | 19:35 | |
| jnoller | can we go back to something dtroyer said | 19:35 |
| jnoller | jamielennox: Windows, OSX and flavors of linux | 19:35 |
| dtroyer | jamielennox: windoes is the best (worst) example, but not exclusive | 19:35 |
| mfer | briancurtin not exactly. that app developer writing the guts of their code may not know who they are dealing with at that point. | 19:35 |
| jnoller | jamielennox: system python is ... not always awesome | 19:35 |
| dhellmann | if we want to replace setuptools, we can do that in the stevedore layer for portability | 19:35 |
| jnoller | quoting dtroyer: "<dtroyer> do we have to call it 'vendor extensions?' is there a functional disctinction from, say, an extension to support a not-yet-incubated API?" | 19:36 |
| jnoller | I think that's an interesting point and one we haven't touched on | 19:36 |
| jnoller | Let's examine solum support for example | 19:36 |
| briancurtin | mfer: that problem is what i had in mind with the "kitchen sink" distro, where you get 'em all | 19:36 |
| jnoller | I think it's perfectly valid for it to be *in the tree* and shipped, but labeled | 19:36 |
| dtroyer | briancurtin: but that's a packaging problem | 19:36 |
| mfer | briancurtin it's more than including all of them. it's how you work with services based on them | 19:36 |
| jnoller | dtroyer: heh, it's a packaging problem, and python packaging is part of the problem, ask dstufft :) | 19:37 |
| dolphm | jnoller: labeled how? | 19:37 |
| *** jcoufal_ has quit IRC | 19:37 | |
| jamielennox | jnoller: having all this stuff 'in tree' is going to be a nightmare | 19:38 |
| dolphm | jamielennox: ++ | 19:38 |
| jnoller | dolphm: Suggestions? We could just say "external" or something akin to that | 19:38 |
| jnoller | jamielennox: Why? | 19:38 |
| jnoller | Look at (for example) Fog, JClouds, libcloud, and others | 19:39 |
| dolphm | unless you have a really strong distinction between stable SDK features and experimental-this-may-change-dramatically-in-the-next-12-minutes you're just going to create the same maintenance nightmare presented by every other client | 19:39 |
| jamielennox | we already will have 9ish core services, allow X many incubating services, and then we try to put extensions in that can cross between everything | 19:39 |
| jnoller | We have close to 25 total services | 19:39 |
| jamielennox | even just for review load | 19:39 |
| Alex_Gaynor | Is this a question we can defer until after we've written more of the core bits? | 19:39 |
| jnoller | Alex_Gaynor: I think that's fair | 19:40 |
| dolphm | Alex_Gaynor: i don't think so - it's a question of "what is the core bits" | 19:40 |
| jnoller | oh no | 19:40 |
| jamielennox | Alex_Gaynor: i think it can be simultaneous | 19:40 |
| dolphm | jnoller: not *that* "core" | 19:40 |
| Alex_Gaynor | dolphm: core openstack projects for starters? And we can consider branching out? | 19:40 |
| jnoller | dolphm: heh :) | 19:40 |
| Alex_Gaynor | keystone, nova, swift, cinder, glance; that should keep us busy for a little while :-) | 19:40 |
| dolphm | Alex_Gaynor: i still think that's too vague/broad/ambitious/unrealistic | 19:40 |
| jnoller | Alex_Gaynor dolphm: I would say current integrated | 19:40 |
| jnoller | dolphm: Current integrated is basically the MVP for the SDK | 19:41 |
| dolphm | Alex_Gaynor: what features of keystone, nova, swift, cinder and glance? which release of those services? | 19:41 |
| briancurtin | there's a BP for this (mostly empty so far) https://blueprints.launchpad.net/unifiedsdk/+spec/define-supported-services | 19:41 |
| dtroyer | There is a service hierarchy of dependencies that we can use to decide order | 19:41 |
| dtroyer | everything needs auth, so Identity is first | 19:41 |
| dtroyer | etc | 19:42 |
| wchrisj | I agree Identity is first | 19:42 |
| bknudson | I'm wondering what libraries are available that we should be making use of? | 19:42 |
| jnoller | Yeah | 19:42 |
| bknudson | e.g., we've got requests-based code in keystoneclient | 19:42 |
| jnoller | bknudson: Example? | 19:42 |
| jamielennox | bknudson: for what | 19:42 |
| dtroyer | Compute, Volume, Image are the next most-depended on services, Object-Store maybe too | 19:42 |
| dolphm | dtroyer: but no one needs *all* of keystone | 19:42 |
| dtroyer | dolphm: true, I haven't broken them down past that yet | 19:43 |
| bknudson | I'm happy with requests, but maybe there's some reason we should stay away from it and use something else? | 19:43 |
| jamielennox | right, auth is first, not necessarily identity | 19:43 |
| dolphm | dtroyer: i'd like to have a philosophical goal to start with, to make it easier to say "no" to feature X being exposed in an SDK | 19:43 |
| jnoller | Identity; Compute, Volume, Image for starters; and of course the core HTTP client (as bknudson says) - fwiw, Alex_Gaynor has an example construct that abstracts the http client away | 19:43 |
| briancurtin | dolphm: an end-user may not, but an admin or someone else may. that goes back to providing light abstractions for someone building an app to use openstack versus someone operating an openstack cloud | 19:43 |
| dolphm | briancurtin: that's why i asked if we were targeting end users or "admins" | 19:43 |
| Alex_Gaynor | end users. | 19:44 |
| bknudson | what would an application need to do with keystone? | 19:44 |
| bknudson | define users? | 19:44 |
| briancurtin | dolphm: i think the ultimate success is if this is useable by end-users. however, along the way, there's no reason this can't be designed so that it's fully usable for admins | 19:44 |
| jamielennox | bknudson: requests is good, i haven't really come across anything else i'd say really needs to be there | 19:44 |
| dolphm | Alex_Gaynor: so, "create domain" would never be exposed in the SDK, correct? | 19:44 |
| dolphm | "create identity is currently a cloud-admin feature, not something any end user would need to use | 19:45 |
| bknudson | maybe we could come up with a scenario that we can aim towards. | 19:45 |
| dolphm | "create identity domain" * | 19:45 |
| *** MaxV has joined #openstack-meeting-3 | 19:45 | |
| jamielennox | dolphm, Alex_Gaynor: i don't think 'never be exposed' is an option for anything - as soon as something is not available then we cannot deprecate the python-*client that does implement it | 19:45 |
| Alex_Gaynor | dolphm: I don't know if I'd necessarily object to having it, but definitely not a priority, and probably documented somewhere special. | 19:45 |
| jamielennox | whether it's wrapped in a nice cross-API layer is different | 19:45 |
| mfer | so, i see we're about 15 minutes to the end of this meeting and it would be great if we had some actionable tasks to do before the next meeting. what can we do that will get us to code? | 19:45 |
| jnoller | the internal openstack.services.keystone would expose that, but not the high level | 19:46 |
| dolphm | Alex_Gaynor: so draw the line between "special" and "not special" for me? and why can't we say "no" to "special" ? | 19:46 |
| edleafe | If it's in the API, it should be accessible in the SDK. Just document the hell out of it. | 19:46 |
| wchrisj | For the first cut, why cant we just take the Identity API and implement based on that? | 19:46 |
| jnoller | wchrisj: +1 | 19:46 |
| Alex_Gaynor | dolphm: things a person using a cloud would want vs. things a person operating a cloud would want | 19:46 |
| bknudson | you mean python-keystoneclient? | 19:46 |
| jnoller | Alex_Gaynor: Got a link to your example internal structure | 19:46 |
| Alex_Gaynor | jnoller: https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/client.py | 19:47 |
| mfer | so, before next week can someone take a shot at identity v2? | 19:47 |
| *** wchrisj has quit IRC | 19:47 | |
| bknudson | identity v2 is deprecated. | 19:47 |
| jamielennox | i would like to be involved in that if we are looking at identity | 19:47 |
| mfer | and yet a load of people are using it | 19:47 |
| mfer | i suggested v2 because it's more widely available in practice. i'm fine with v3 but we should likely support both at some point | 19:48 |
| bknudson | jamielennox: can you link to your auth plugins? | 19:48 |
| jnoller | Is this structure that Alex_Gaynor laid out a "good enough" starting point for us to build out the basics and get it functioning? | 19:48 |
| jamielennox | so i've been talking with dtroyer recently about the current managers approach, do we want to keep that design? eg identity.users.list() | 19:48 |
| jnoller | Alex_Gaynor might want to chime in why its done that way | 19:48 |
| Alex_Gaynor | Please note that this is *far* less concerned with the public API, and more concerned with the internals. | 19:48 |
| Alex_Gaynor | identity.uysers.lists() vs. identity.list_users() is of no concern to me :-) | 19:49 |
| *** wchrisj has joined #openstack-meeting-3 | 19:49 | |
| jamielennox | https://github.com/openstack/python-keystoneclient/tree/master/keystoneclient/auth | 19:49 |
| briancurtin | #topic API status | 19:49 |
| *** openstack changes topic to "API status (Meeting topic: python-openstacksdk)" | 19:49 | |
| Alex_Gaynor | The key idea is clean seperation between data and executing HTTP requests. | 19:49 |
| edleafe | Alex_Gaynor: And that design can be used with any SDK design | 19:50 |
| dolphm | jnoller: just glancing at the "strawman," it makes a ton of undocumented assumptions | 19:50 |
| Alex_Gaynor | Indeed | 19:50 |
| jnoller | dolphm: Which one | 19:50 |
| dolphm | https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/client.py | 19:50 |
| jnoller | thanks' | 19:50 |
| edleafe | dolphm: that isn't really an API strawman; the one I outlined in https://github.com/stackforge/python-openstacksdk/tree/master/api_strawman/pystack is a working design | 19:51 |
| jnoller | For a basic start on the *public* api, we have two rough drafts: https://github.com/stackforge/python-openstacksdk/blob/master/api_strawman/README.rst | 19:51 |
| edleafe | fwiw, Alex's code could work well in mine | 19:51 |
| *** lcheng_ has quit IRC | 19:52 | |
| dolphm | why is any of this in the tree? | 19:53 |
| jnoller | I'd say let's build out from Alex's core, and then get agreeance on the public API - I definitely prefer the "client = OpenStackClient(KeystoneAuth('http://localhost:8000/', 'alex', '****'))" syntax | 19:53 |
| briancurtin | i believe dolphm did mention previously to back them out and then run through gerrit reviews (or something along those lines) | 19:53 |
| dolphm | if the goal is a solid UX, committing "ideas" is a rough way to start | 19:54 |
| jnoller | dolphm: Completely fair: This was my first stab at stack forging - so that's my bad. | 19:54 |
| jnoller | dolphm: Also, there were not enough eyeballs (again, my fault) | 19:54 |
| mfer | jnoller given what we know and the api strawman... is it time for someone to roll the initial identity client code and get it up for review? | 19:55 |
| jnoller | mfer: yeah I was typing | 19:55 |
| jnoller | So goals by next meeting: 1: Back out the straw man, 2: Get the core http stuff done enough to begin work on the identity work | 19:56 |
| dolphm | 1: https://review.openstack.org/#/c/75362/ | 19:56 |
| jnoller | 3: Get rough identity client | 19:56 |
| wchrisj | Excellent | 19:56 |
| jnoller | Ok so 1 is done | 19:56 |
| briancurtin | #action https://review.openstack.org/#/c/75362/ | 19:56 |
| bknudson | one of the things that we might want to decide is overall -- do we go with an async implementation (with callbacks) or a simpler synchronous one. | 19:56 |
| jnoller | bknudson: That is a question Alex_Gaynor's proposal was trying to avoid | 19:57 |
| briancurtin | #action core HTTP layer to build on | 19:57 |
| wchrisj | Even if there is a lot of churn/iterating at first, code talks. | 19:57 |
| briancurtin | #action rough identity client | 19:57 |
| Alex_Gaynor | jnoller: not so much avoid, as allow us to answer multiple ways | 19:57 |
| jnoller | Alex_Gaynor: yes | 19:57 |
| Alex_Gaynor | bknudson: I think the inital API we should expose shoudl be synchrnous, but the internals should make it very easy to do an async (twisted, asyncio, etc.) one without rewriting EVERTYHIGN | 19:57 |
| jnoller | I apologize all, I have a hard stop now: mfer those tasks look good? | 19:57 |
| bknudson | Alex_Gaynor: ok, will be interesting to see examples. | 19:58 |
| mfer | jnoller sounds good to me | 19:58 |
| jnoller | thanks all - brian you got this :) | 19:58 |
| briancurtin | 2 minutes on the clock...anything else to cover? any other action points we want to see? | 19:58 |
| Alex_Gaynor | I think I might have a burrito for lunch. | 19:59 |
| jamielennox | mfer: so are you taking those 3 jobs? | 19:59 |
| dolphm | jnoller: the gate also appears to be already wedged, as there are no newlines in the requirements files | 19:59 |
| dolphm | https://review.openstack.org/#/c/75852/ | 19:59 |
| jamielennox | as i have re-written essentially the first 2 recently (so i have an interest) | 19:59 |
| *** jpomero has quit IRC | 20:00 | |
| mfer | jamielennox ha... nope. i just want to make sure they are there. for us wchrisj is going to be doing more of the coding | 20:00 |
| dtroyer | jamielennox: as long as you stop stuffing things into Session ;) | 20:00 |
| wchrisj | I'd be glad to help get this done | 20:00 |
| *** Sukhdev has joined #openstack-meeting-3 | 20:00 | |
| jamielennox | dtroyer: oh, there's more | 20:01 |
| dtroyer | rename it Client then | 20:01 |
| edleafe | I'm looking to help with the code, too | 20:01 |
| briancurtin | should we take this back to #openstack-sdks? | 20:01 |
| briancurtin | #endmeeting | 20:01 |
| *** openstack changes topic to "Free for all (Meeting topic: Horizon)" | 20:01 | |
| openstack | Meeting ended Tue Mar 4 20:01:42 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.html | 20:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.txt | 20:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-03-04-19.00.log.html | 20:01 |
| *** jpomero_ has joined #openstack-meeting-3 | 20:03 | |
| *** jamielennox has left #openstack-meeting-3 | 20:08 | |
| *** jcoufal has joined #openstack-meeting-3 | 20:14 | |
| *** terrylhowe has joined #openstack-meeting-3 | 20:23 | |
| *** terrylhowe has left #openstack-meeting-3 | 20:23 | |
| *** jpich has left #openstack-meeting-3 | 20:24 | |
| *** briancurtin has left #openstack-meeting-3 | 20:25 | |
| *** jnoller has quit IRC | 20:47 | |
| *** sivel has left #openstack-meeting-3 | 20:48 | |
| *** MaxV has quit IRC | 20:54 | |
| *** jcoufal has quit IRC | 20:58 | |
| *** jcoufal has joined #openstack-meeting-3 | 21:03 | |
| *** julim has quit IRC | 21:31 | |
| *** jcoufal has quit IRC | 21:50 | |
| *** jcoufal has joined #openstack-meeting-3 | 21:52 | |
| *** troytoman is now known as troytoman-away | 21:55 | |
| *** Alex_Gaynor has left #openstack-meeting-3 | 21:56 | |
| *** lblanchard has quit IRC | 21:58 | |
| *** enykeev has quit IRC | 21:59 | |
| *** Sukhdev has quit IRC | 22:00 | |
| *** lcheng_ has joined #openstack-meeting-3 | 22:03 | |
| *** troytoman-away is now known as troytoman | 22:06 | |
| *** peristeri has quit IRC | 22:17 | |
| *** dhellmann is now known as dhellmann_ | 22:18 | |
| *** mfer has quit IRC | 22:24 | |
| *** devlaps1 has joined #openstack-meeting-3 | 22:28 | |
| *** devlaps has quit IRC | 22:29 | |
| *** jpomero_ has quit IRC | 22:51 | |
| *** lpetrut has quit IRC | 23:06 | |
| *** jcoufal has quit IRC | 23:06 | |
| *** jcoufal has joined #openstack-meeting-3 | 23:30 | |
| *** david-lyle has quit IRC | 23:34 | |
| *** jcoufal has quit IRC | 23:39 | |
| *** jcoufal has joined #openstack-meeting-3 | 23:41 | |
| *** mwagner_lap has quit IRC | 23:44 | |
| *** lcheng_ has quit IRC | 23:52 | |
| *** cjellick has quit IRC | 23:56 | |
| *** lcheng_ has joined #openstack-meeting-3 | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!