Wednesday, 2014-12-03

*** etoews has quit IRC00:08
*** stevemar has quit IRC00:28
*** etoews has joined #openstack-sdks00:34
*** tellesnobrega has quit IRC00:37
*** tellesnobrega has joined #openstack-sdks00:44
*** tellesnobrega_ has quit IRC00:46
*** etoews has quit IRC01:08
*** stevemar has joined #openstack-sdks01:42
*** rmcall has quit IRC01:53
*** tellesnobrega_ has joined #openstack-sdks02:04
*** etoews has joined #openstack-sdks02:04
*** sigmavirus24 is now known as sigmavirus24_awa02:12
*** ayoung has joined #openstack-sdks02:17
*** etoews has quit IRC02:38
*** etoews has joined #openstack-sdks02:51
*** sigmavirus24_awa is now known as sigmavirus2402:52
*** etoews has quit IRC03:00
*** etoews has joined #openstack-sdks03:34
*** etoews has quit IRC03:39
*** jamielennox is now known as jamielennox|away03:44
*** jamielennox|away is now known as jamielennox04:20
*** etoews has joined #openstack-sdks04:35
*** etoews has quit IRC04:40
*** sigmavirus24 is now known as sigmavirus24_awa05:15
*** gus has joined #openstack-sdks05:17
gus.. So what's the general status of pythonsdk?05:17
gusneutron would like to clean up / unify our CLI, and we'd like to (basically) abandon neutronclient.05:19
gusI presume the future is openstackclient CLI using pythonsdk?  Would it be reasonable for me to flesh out the neutron bits of openstackclient using pythonsdk, or is the latter not ready for that yet?05:20
*** britthouser has quit IRC05:21
*** tellesnobrega_ has quit IRC05:28
*** stevemar has quit IRC05:36
*** rmcall has joined #openstack-sdks05:52
*** rmcall has joined #openstack-sdks05:54
*** rmcall_ has joined #openstack-sdks05:59
*** rmcall has quit IRC06:02
*** rmcall_ has quit IRC06:04
*** rmcall has joined #openstack-sdks06:04
*** briancurtin has quit IRC06:06
*** britthouser has joined #openstack-sdks06:14
*** k4n0 has joined #openstack-sdks06:20
*** etoews has joined #openstack-sdks06:37
*** etoews has quit IRC06:41
*** rmcall_ has joined #openstack-sdks07:05
*** rmcall has quit IRC07:08
*** rmcall_ is now known as rmcall07:08
*** terrylhowe has quit IRC07:10
*** rmcall has quit IRC07:19
*** etoews has joined #openstack-sdks07:37
*** etoews has quit IRC07:42
*** openstackgerrit has quit IRC07:50
*** openstackgerrit has joined #openstack-sdks07:50
*** etoews has joined #openstack-sdks08:38
*** etoews has quit IRC08:42
*** tellesnobrega_ has joined #openstack-sdks10:18
*** terrylhowe has joined #openstack-sdks10:46
*** tellesnobrega_ has quit IRC11:02
*** k4n0 has quit IRC11:23
*** pm90_ has joined #openstack-sdks13:14
*** bknudson1 has quit IRC13:21
*** dekozo has joined #openstack-sdks13:39
*** bknudson has joined #openstack-sdks13:40
*** etoews has joined #openstack-sdks13:47
*** sigmavirus24_awa is now known as sigmavirus2413:54
sigmavirus24gus I think the openstacksdk has support for neutron but I'm not familiar with the maturity of that support. so maybe you could try adding that support to the CLI and fix the parts that don't match your expectations?13:55
openstackgerritTerry Howe proposed openstack/python-openstackclient: Proof of concept for SDK integration into OSC
terrylhowegus: was something I was in the midle of, but I’ve been sidetracked.  If you have some cycles take a look at it.  I think the SDK is far enough along to be used like this, but a recent change to the list method in the SDK has broken the listing for Neutron14:32
terrylhowegus: feel free to patch that review if you like or start your own, not sure if you’d have perms to patch it.  I had create working and list (with a change to the SDK), but it still needs update, delete and show.  Also fixing the tests, so there is still a fair amount to do.  You really need to get with dtroyer on this though14:35
*** etoews has quit IRC14:35
*** briancurtin has joined #openstack-sdks14:52
*** briancurtin has joined #openstack-sdks14:52
briancurtingus: i missed your messages about 9 hours ago, but yes, OSC is planning to use SDK, but i would check with terrylhowe on OSC integration as he's looking into that now. as for general status of SDK, we're building out high-level interfaces on top of our resource layer now - has an example of what we're building for object storage14:59
*** ayoung has quit IRC15:00
*** tellesnobrega_ has joined #openstack-sdks15:12
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Have resource list continue if limit reached
*** etoews has joined #openstack-sdks15:31
*** etoews has quit IRC15:35
*** f13o has quit IRC15:36
*** pm90_ has quit IRC15:40
*** etoews has joined #openstack-sdks15:47
*** rmcall has joined #openstack-sdks15:53
*** stevemar has joined #openstack-sdks15:55
*** etoews_ has joined #openstack-sdks15:58
*** etoews has quit IRC16:01
notmynamegood morning16:05
*** tellesnobrega_ has quit IRC16:28
*** pm90_ has joined #openstack-sdks16:33
*** mattfarina has joined #openstack-sdks17:32
*** rmcall has quit IRC17:39
*** rmcall has joined #openstack-sdks17:44
*** ayoung has joined #openstack-sdks17:46
*** pm90_ has quit IRC17:49
*** pm90_ has joined #openstack-sdks17:50
*** rmcall has quit IRC18:06
*** rmcall has joined #openstack-sdks18:07
*** rmcall_ has joined #openstack-sdks18:11
*** rmcall has quit IRC18:12
*** rmcall_ is now known as rmcall18:12
*** etoews_ has quit IRC18:18
*** etoews has joined #openstack-sdks18:19
*** etoews has quit IRC18:25
*** etoews has joined #openstack-sdks18:45
*** bknudson has quit IRC18:50
openstackgerritDean Troyer proposed openstack/python-openstackclient: Command object docs: server, server image
openstackgerritDean Troyer proposed openstack/python-openstackclient: Add documentation of interactive mode
dtroyerstevemar: what do you want to do about
dtroyerthat, plus are all we have left from the list for 1.0.019:38
dtroyerThe other two doc reviews are optional, if they are ready they can do in too, but I don't want to wait for them if we get into another gate/check loop19:38
*** bknudson has joined #openstack-sdks19:41
stevemardtroyer, right, so that one is the whole need for OS_USER_DOMAIN_ID and OS_PROJECT_DOMAIN_ID19:41
dtroyerI see bknudson's argument…so just close the bug and move on?19:42
stevemardtroyer, we were defaulting it to default before, but during the API shuffle since those are controlled by keystoneclient, we didn't default them any longer19:42
stevemarright, it's obnoxious to default it to something19:42
stevemarlet the user set an environment variable or pass them in through the CLI19:43
dtroyerthat's a change to user behaviour though…"why do I need this now?  what's a v3 API?"19:43
stevemardtroyer, well they should know what the v3 API is, since it's still v2 by default19:43
stevemarand they supposedly changed it to v319:44
bknudsondo they usually get env vars from an rc file? they can put it in there.19:44
dtroyerthat's not always going to be the case.19:44
stevemarbknudson, yep19:44
dtroyeras soon as a deployer turns on v3 (that doesn't have it now, say) users will break19:45
bknudsonwell, I guess OS_USER_DOMAIN_ID and OS_PROJECT_DOMAIN_ID need to be set to something so it might as well be "default"19:45
bknudsonis that what the change was?19:45
bknudsonmaybe I felt it was happening in the wrong place19:46
stevemarbknudson, i think that's what the change was19:46
dtroyerthat's possible, there are more than a few moving parts to this19:46
stevemardtroyer, bknudson, ref:
bknudsonhow about have the environment variable / argument default to "default" instead?19:47
bknudsonthe code as it is just seems weird19:48
bknudsonmaybe that's just because of the "moving parts"19:49
stevemarbknudson, those are controlled by ksc though19:50
bknudsonmake the fix in ksc then19:50
stevemarbknudson, but that definitely seems like the wrong place, OSC should handle it because it consumed ksc19:55
stevemarksc shouldn't have any business defaulting things19:55
bknudsonif ksc is doing the cli arguments and env vars then it should be defaulting to something that might work rather than being guaranteed to fail19:57
*** ycombinator_ has joined #openstack-sdks20:27
dtroyerOSC does all of its own args and env vars, separate from what KSC's cli might do20:41
*** ycombinator_ has quit IRC21:01
*** jamielennox is now known as jamielennox|away21:42
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Add object_store resource documentation
*** ycombinator_ has joined #openstack-sdks21:57
*** pm90__ has joined #openstack-sdks22:02
*** pm90_ has quit IRC22:04
*** tellesnobrega_ has joined #openstack-sdks22:05
*** ycombinator_ has quit IRC22:10
*** pm90__ has quit IRC22:20
*** pm90_ has joined #openstack-sdks22:21
*** pm90_ has quit IRC22:25
*** mattfarina has quit IRC22:30
*** pm90_ has joined #openstack-sdks22:53
*** jamielennox|away is now known as jamielennox23:09
*** etoews_ has joined #openstack-sdks23:10
*** etoews has quit IRC23:14
*** bknudson has quit IRC23:19
*** etoews_ has quit IRC23:27
*** etoews has joined #openstack-sdks23:30

Generated by 2.14.0 by Marius Gedminas - find it at!