Thursday, 2015-05-14

*** stevelle has joined #openstack-sdks00:04
*** Qiming has joined #openstack-sdks00:05
*** Qiming has quit IRC00:18
*** etoews has quit IRC01:09
*** mattfarina has joined #openstack-sdks01:13
*** mattfarina has quit IRC01:16
*** sigmavirus24 is now known as sigmavirus24_awa01:18
*** Qiming has joined #openstack-sdks01:41
*** Qiming_ has joined #openstack-sdks01:42
*** Qiming has quit IRC01:46
*** Qiming__ has joined #openstack-sdks01:47
*** Qiming_ has quit IRC01:50
*** Yanyanhu has joined #openstack-sdks01:54
*** Qiming__ is now known as Qiming01:58
*** pm90_ has joined #openstack-sdks04:33
*** pm90__ has joined #openstack-sdks04:46
*** pm90_ has quit IRC04:47
*** pm90__ has quit IRC05:04
*** toabctl has quit IRC05:21
*** jlvillal has quit IRC05:26
*** jlvillal has joined #openstack-sdks07:29
*** karimb has joined #openstack-sdks07:37
*** aufi has joined #openstack-sdks07:42
*** bnemec has quit IRC09:13
*** bnemec has joined #openstack-sdks09:13
*** trown|outttypeww is now known as trown09:27
*** Yanyanhu has quit IRC10:15
*** Qiming has quit IRC10:27
*** jamielennox is now known as jamielennox|away10:58
*** chlong has joined #openstack-sdks11:48
*** thrash|g0ne is now known as thrash11:50
*** stevemar has joined #openstack-sdks12:38
*** bknudson has quit IRC12:42
*** bknudson has joined #openstack-sdks13:41
*** britthouser has joined #openstack-sdks13:56
*** bradbeam_ has joined #openstack-sdks14:00
*** britthou_ has joined #openstack-sdks14:01
Shrewsmordred: so, quick off-the-top-of-my-head example of how this new o-c-c command line might operate:
Shrewsgood? bad? missing stuff?14:01
*** bradbeam_ has left #openstack-sdks14:01
*** bradbeam has quit IRC14:02
Shrewsor maybe you or greghaynes has already started on something14:03
mordredShrews: I think that looks great. dtroyer was saying he thinks the commands should actually be added to osc14:03
Shrewsoh, hrm14:03
Shrewswell, that could work too14:03
mordredso like "openstack cloud add" and "openstack cloud merge" maybe? (with the same semantics you have there)14:04
*** britthouser has quit IRC14:04
Shrewsi'm cool with that14:04
dtroyerit would be simple to do as a plugin, could me merged into the repo too14:04
dtroyerI'll likely be an ass about the command structure though… ;)14:04
mordredShrews, dtroyer: I was also thinking a "openstack cloud use" might be nice ... let you set a 'current cloud' on the command line14:05
*** sigmavirus24_awa is now known as sigmavirus2414:05
dtroyerah, I did think of that wrt interactive use, wasn't sure about from the shell though14:05
mordreddtroyer: well, I've never written an osc command and I don't think Shrews has either - so it'll be fun14:05
Shrewsi've never even seen osc code, so... yeah14:06
mordreddtroyer: I was thinking from the shell maybe openstack cloud use would write out a ~/.openstackcloud or something with the cloud name in it or something14:06
mordreddtroyer: I have not fully thought this through :)14:06
mordreddtroyer: just wait till I bother you with wanting "openstack server list" to be able to handle multi-clouds :)14:07
dtroyermy hesitation on doing it interactively is in users forgetting and wondering why it Doesn't Work(TM).14:07
mordreddtroyer: yah. that's the biggest issue there14:07
dtroyermordred: heh, I started that one already!14:07
mordreddtroyer: NEAT!14:07
mordredit's like we share one brain between us14:07
dtroyerthat's where the damn cats came from!14:08
Shrewsmordred: you having half a brain sounds about right14:08
* Shrews hides14:08
* mordred throws a thousand used loofas at Shrews14:08
*** mattfarina has joined #openstack-sdks14:10
mordredgreghaynes: ^^ when you awaken, you probably want to read that14:17
dtroyermordred, Shrews: I did a _really_ _quick_ rename of the sample OSC plugin to osc-cloud if you want to look at what an OSC plugin looks like:
mordreddtroyer: do you thnk it should be a plugin and not just in osc?14:21
* mordred could go either way, honestly14:21
mordredsince osc depends on o-c-c - if occ provided an osc plugin, it would be six in one half a dozen in the other14:21
dtroyerI'd start as a plugin, we could merge it later?  I just start experimantal thigs as plugins these days14:21
dtroyerbut I wouldn't reject adding it directly either14:22
*** britthou_ has quit IRC14:22
mordreddtroyer: (you didn't git add osccloud14:22
dtroyerI said it was a quick rename of the default.  didn't change the commands yet either ;)14:22
mordreddtroyer: there's no source dir though ...14:22
mordredunless you don't need any source code to write pugins. *MIND*BLOWN*14:23
dtroyerI wish I could claim lack of caffiene…there it is14:23
dtroyermaking this into a cookiecutter thing is on my list…someday…14:25
Shrewsdtroyer: mordred: i assume a plugin wouldn't require a blueprint spec to first get approved, yeah?14:27
mordreduhm. no14:27
Shrewsb/c, i'm all about simplicity14:27
mordredShrews: so - looking at that, it seems like if we add the needed source to occ - but _don't_ add cliff or openstackclient to requirements - instead, add them to test-requirements14:27
mordredthat way we can functional test that the occ plugin works with openstackclient14:28
mordredbut if someone just installs occ without osc, they don't get osc depends sucked in14:28
mordredbut we can register the entry point14:28
mordredso if they do later install osc, they will magically get everythign working14:28
Shrewsthat magic sounds acceptable14:29
dtroyerI wouldn't put the OSC (cliff) command classes into o-c-c, just the implementation underneath them14:29
mordreddtroyer: you'd make a totally separate repo for the plugin?14:29
*** shakamunyi has joined #openstack-sdks14:29
dtroyerif this were optional, yes, the more I think about it, in the end here, no14:30
dtroyerif o-c-c in OSC were optional14:30
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in object_store proxy
mordredyah. seems like something that just wants to be a thing14:30
dtroyerso that plugin is good for a pattern to build the command classes, less to look at than OSC itself14:30
dtroyerand that pushes me to putting the commands into OSC repo14:31
mordredI believe I am now of that opinion too, from the talking14:31
dtroyerso given that, it deserves a new top-level dir: or something14:32
dtroyerI've been putting litle stuff like this into openstackclient.common but that feels dirty14:33
* mordred likes dirty things14:33
stevemarkeep things pg mordred !14:33
dtroyerthat's where the module andtiming commands like for example14:34
Shrewsso... no plugin?14:34
* mordred hands stevemar something inappropriate14:34
mordredShrews: yah. it sounds like just a patch to osc14:34
stevemardtroyer, the common module has been getting a bit overloaded14:34
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in image proxies
dtroyerstevemar: I think it stll makes sense for commands that cross REST APIs, but for internal bits like this I'd favor a better location14:35
stevemarquota/limit/extensions can stay there14:36
stevemardo we have utils in there?14:36
stevemari suppose they could stay put14:36
*** toabctl has joined #openstack-sdks14:37
*** aufi has quit IRC14:37
*** Shrews has quit IRC14:38
*** mordred has quit IRC14:40
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Orchestration proxy changes
*** mordred has joined #openstack-sdks14:42
*** Shrews has joined #openstack-sdks14:43
*** barra204 has joined #openstack-sdks14:43
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in telemetry proxy
dtroyerstevemar: what do you think about skipping osc meeting today?  I didn't do a release and probably will not this close to the weekend14:50
stevemardtroyer, thats fine with me, my schedule is packed til the summit14:52
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in volume proxy
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Orchestration proxy changes
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in object_store proxy
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Common list method for proxies
*** pm90_ has joined #openstack-sdks15:17
* greghaynes awakens to a great many highlights15:19
greghaynesmordred: ohai15:19
mordredgreghaynes: tl;dr - we're going to add your idea to osc15:19
mordredgreghaynes: Shrews may alraedy be working on it15:19
greghaynesok, trying to parse the bits about it being optional and living in multiple places?15:19
Shrewswell, not *yet*15:20
greghaynesdoes osc not currently depend on os-c-c}15:20
*** pm90_ has quit IRC15:20
dtroyergreghaynes: it does…skip the commants about OSC plugins, we're not doing that part15:20
*** pm90_ has joined #openstack-sdks15:20
greghaynesok, awesome15:21
greghaynesand command structure, I was thinking <cmd> cloud add <cloudname> <destfile?15:21
Shrewsgreghaynes: is this something you want to work on? i wasn't sure of your interest level... was just going to start doing it if no one else was15:23
greghaynesShrews: Yea, I can do it, started poking a bit at it in o-c-c yesterday15:23
Shrewsgreghaynes: cool. i can stick to shade & ansible things, then15:24
greghaynesoh, mordred did a hack way15:24
mordredI did?15:24
mordredoh - the just-add-it-to-devstack thing?15:24
mordredI think once there is an osc command, we should just run that15:24
briancurtinterrylhowe: i am going to just disable any tests that use httpretty because it is somehow once again fucking this entire process up even after hacking in that version. once the list change goes through they won't actually be needed.15:31
*** etoews has joined #openstack-sdks15:32
terrylhowebriancurtin: sounds good15:34
stevemardtroyer, so the meeting today is cacled?15:37
* stevemar fights against the urge to reply to the ML with a joke15:37
terrylhoweno meeting today?15:39
dtroyerterrylhowe: no15:40
dtroyerstevemar: that's evidence enough on why it should be...15:41
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Remove httpretty
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Remove httpretty
*** etoews_ has joined #openstack-sdks15:47
*** etoews_ has quit IRC15:48
openstackgerritMerged stackforge/python-openstacksdk: Changes for get calls in object_store proxy
mordreddtroyer: actually - you like go, right?16:04
mordredor someone in here does iirc16:04
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Remove httpretty
greghaynessurely someone on the internet likes go16:05
dtroyerGO GO GO!!!16:07
dtroyerbut I grew up in Pascal so it's like going home16:07
dtroyer(pun intended)16:07
sigmavirus24greghaynes: not for long?16:12
sigmavirus24<trolling>the only good part of go is the package management</trolling>16:14
openstackgerritMerged stackforge/python-openstacksdk: Changes for get calls in network proxy
openstackgerritMerged stackforge/python-openstacksdk: Changes for get calls in telemetry proxy
*** shakamunyi has quit IRC16:27
*** barra204 has quit IRC16:28
openstackgerritMerged stackforge/python-openstacksdk: Remove httpretty
briancurtinterrylhowe: any thought on for list calls? i'm trying to squeeze in a change for head as well, but should be pretty much in line with what we've already done for get since it's similar16:39
terrylhowebriancurtin: I’m trying to slog through all these get changes and then list16:40
briancurtinok cool16:40
terrylhoweI should get to list soon16:40
openstackgerritMerged stackforge/python-openstacksdk: Changes for get calls in volume proxy
openstackgerritMerged stackforge/python-openstacksdk: Orchestration proxy changes
briancurtinterrylhowe: yeah, documenting that stuff is going to be really hard, but the one that's in there appears to be pretty accurate - should i still remove that one or just not add any others while finishing it out? I had looked at making query params some type of list attached to each resource, and maybe we can do that later on17:04
terrylhowewell, not add any others will speed things up for sure.17:04
terrylhowequery parms on the resource is an interesting idea17:05
briancurtinterrylhowe: i had looked at it being a list or a dict, and then some type of cross-check against what params are sent to the list method. might work, might be too much. we kind of do need the prop functionality there, as evidenced by the changes-since/changes_since one in that review17:07
briancurtinterrylhowe: and yeah, i'll stick with not adding any others. the follow-on changes would purely be accepting the **params and setting the appropriate paginated= kwarg17:31
terrylhowesounds good briancurtin I’ll post a couple other discussion points, but I still want to mess with it a little17:37
*** jsavak has joined #openstack-sdks17:51
greghaynesmordred: annoying thing about this outputting clouds.yaml - if we grab the config to output from the os-c-c config that osc loads then were going to be serializing all the defaults into the clouds.yaml18:06
mordredbriancurtin: I was about to ask how you set up your test_cloud cloud for your functional tests ... but then realized that you arent' running those in the gate yet18:06
mordredgreghaynes: I'm not following how that's annoying?18:06
mordredgreghaynes: but it's possible a different sequence of words would help my age-adled brain18:07
greghaynesno, its a valid point18:07
greghayneswell see how it works because whynot18:08
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Common list method for proxies
*** jlvillal has quit IRC18:36
*** jlvillal has joined #openstack-sdks18:41
*** pm90_ has quit IRC19:08
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Common head method for proxies
openstackgerritMerged stackforge/python-openstacksdk: Common list method for proxies
*** stevemar has quit IRC19:25
*** pm90_ has joined #openstack-sdks19:45
*** openstackgerrit has quit IRC19:52
*** openstackgerrit has joined #openstack-sdks19:52
*** trown is now known as trown|outttypeww20:01
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Common head method for proxies
briancurtinterrylhowe: thanks for getting that head one20:43
briancurtingoing through the list changes now20:43
openstackgerritMerged stackforge/python-openstacksdk: Common head method for proxies
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for compute proxy list calls
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Fix comment error on gets and heads
terrylhowebriancurtin: ^^ might want to take a quick look at that one and rebase if it looks good20:55
terrylhoweI’d approved probably 4 get changes before I noticed it20:56
briancurtinterrylhowe: ah, crap. yeah. am currently making a minor tweak to _get and will rebase the rest of those20:57
*** chlong has quit IRC21:08
*** jsavak has quit IRC21:10
*** openstackgerrit has quit IRC21:22
*** openstackgerrit has joined #openstack-sdks21:22
*** mattfarina has quit IRC21:44
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Move compute limits to new _get API
openstackgerritgreghaynes proposed openstack/os-client-config: Add set_one_cloud method
openstackgerritgreghaynes proposed openstack/python-openstackclient: Create cloud update command
greghaynesmordred: ^21:51
mordredgreghaynes: NEAT!21:53
greghaynesI kind of need to figure out the tests for the osc change21:54
greghaynesbut seems to work21:54
greghaynesSpamapS: Shrews ^ youall too22:00
greghaynesmight find that of interest22:00
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Move compute limits to new _get API
openstackgerritMerged stackforge/python-openstacksdk: Fix comment error on gets and heads
*** bknudson has quit IRC22:20
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for compute proxy list calls
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in image proxies
mordredgreghaynes: left a -1 on the o-c-c change22:26
mordredgreghaynes: it's a nit-ish thing - but easy enough tofix22:26
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for database proxy gets
openstackgerritBrian Curtin proposed stackforge/python-openstacksdk: Changes for get calls in image proxies
openstackgerritAmey Bhide proposed openstack/python-openstackclient: Add support for v2 image update commands
*** shakamunyi has joined #openstack-sdks22:47
*** barra204 has joined #openstack-sdks22:47
mordredjamielennox|away: so, now that keystoneauth exists - porting openstacksdk to it should be a thing, right?23:02
sigmavirus24mordred: but first, is there documentation?23:02
dtroyerplease no?  sdk should have _no_ dependencies like that or we'll never leave the version hell we are in23:03
mordredsigmavirus24: not yet23:03
mordreddtroyer: I think keystoneauth is the one you do want23:03
mordredbecause it doesnt' depend on the other things23:03
briancurtinif it's not documented it won't be considered at all.23:03
mordredwell, it _will_ have by the 1.0 release23:03
*** barra204 has quit IRC23:04
briancurtinalready had enough of a time dealing with current "documentation"23:04
*** shakamunyi has quit IRC23:04
*** redrobot has quit IRC23:04
dtroyerbut the server-side vs client-side differences will not go away in that case23:04
mordreddtroyer: what do you mean?23:04
dtroyerthat's why the SDK is client-saviour for non-server use23:04
mordredkeystoneauth is just about getting a session to auth against a keystone23:05
mordredit's not all the server related things23:05
*** redrobot has joined #openstack-sdks23:05
mordredunless I am missing something23:05
dtroyerbut if both server and client use it, then we never leave the dependency version hell23:05
*** redrobot is now known as Guest1989523:05
mordredauth-ing against a keystone shold be versionless?23:06
* mordred may not grok the problem23:06
dtroyerthe library itself.  installing master clients on a stable/xyz server is broken23:06
dtroyerwhy we did stable/kilo for client and libs23:06
mordredone sec23:06
*** morganfainberg has joined #openstack-sdks23:07
morganfainbergmordred: o/23:07
mordredif openstacksdk can't use it without hell, then something is broken - but I've asked morgan to come in because he knows plans better23:07
mordredmorganfainberg: we're talking about keystoneauth23:08
mordredandwhether or not it will be subject otthe client lib/ server hll23:08
mordredbut you know more than me23:08
morganfainbergThe client server hell?23:08
morganfainbergI need a little more context.23:08
dtroyerpulling keystoneauth out of ksc doesn't change anything in the version dependency dept if both clients and servers use it23:08
dtroyerre master vs stable branches23:08
mordredmorganfainberg: installation of master clients on stable servers breaking things23:08
morganfainbergUnfortunately, yes it will be used by both. But the hope is we can get the depends very very very very very narrow.23:09
morganfainbergBut where it will be used by both is via clients23:09
morganfainbergNot direct by the server.23:09
dtroyerso how do we do stable/kilo with liberty-era clients?23:10
*** chlong has joined #openstack-sdks23:10
mordredok. we need to sit down and figure this out at the summit23:10
mordredbecause I now how two conflicting desires23:10
mordreda) use openstacksdk23:10
morganfainbergMaybe we need to be smarter about this23:10
mordredb) use keystoneauth23:10
dtroyerseriously yes… this will put me over the edge and I'll just work on Go clients, or any other language without this damn installation nightmare23:10
mordredand that makes me sad panda23:10
dtroyeror we vendor it in multiple places and keep the vendored code minimal23:11
morganfainbergWe might be able to dodge this with a minor split for a server version namespace.23:11
dtroyeror we put the version in the package name23:11
mordredI do _not_ want to use a second implementation of keystone auth client -that's just a silly idea - btu I also don't want dtroyer to quit23:11
morganfainbergI'm open to doing some smart namespace things to make this less icky.23:11
morganfainbergSo we dodge the client server hell.23:12
dtroyerimport keystoen.auth_1_2_7 is one answer…23:12
morganfainbergThis is a new thing. Let's treat it like a new thing.23:12
mordredEW GROSS23:12
dtroyerso we can install them all ;)23:12
mordredwell, I mean - I don't understand why liberty keystoneauth should break essex nova23:12
morganfainbergAnd not limit ourselves to "we sucked at this in the past"23:12
mordredand I think that if that is the case23:13
mordredthen something is broken23:13
morganfainbergmordred: right. So how can we dodge that? And I don't want to vendor it.23:13
dtroyerwe have to be able to install multiple versions of a thing.  there are few ways to do it: venv/chroot/etc, versions in mnames, or vendor23:13
mordredkeystone auth, of all the things, MUST handle ALL of the versions and have a 100% unchanging 100% compat python interface23:13
morganfainbergmordred: that is the plan with the 1.x series.23:13
dtroyerI would love to be missing something from that list23:13
mordreddtroyer: why do we have to install multiple versions of things?23:13
*** dstufft has quit IRC23:14
morganfainbergIf we move to a 2.x I plan on making them install side-by-side23:14
dtroyerto support stable/* branches and still be able to install a client on the server itself23:14
dtroyeror devstack23:14
mordredif keystoneauth releases a 1.0 and never releases a new version, then we should not have the upgrade churn issue we had with python-*clent where people kept chasing pretty23:14
morganfainberg1.x of ksa can grow fixes but not new crazy deps.23:15
mordredzebra keystone auth should be able to be installed on a server running stable/liberty nova and nothing should break or else we shoudl all go home23:15
morganfainbergIt is meant to be *stable*23:15
morganfainberglike *really* stable.23:15
mordredit has to be23:15
mordredor else it's useless23:15
dtroyerso the auth plugin objects need to be finished23:15
morganfainbergI'm planning on ripping all the g-r madness out of it too.23:15
morganfainbergdtroyer: plugins are hopefully always going to be separate packages besides the very basic ones. And again. Very limited requires.23:16
dtroyerI hope so…it feels like the base interface is still changing though.  maybe I'm not reading jamie's reviews closely enough23:17
morganfainbergSeriously, I want ksa to be like libc, if you install v1 or v2 they can both play nice.23:17
dtroyerit will have to23:17
morganfainbergdtroyer: I expect it to change until 1.x23:17
morganfainbergThe 0.1.0 release is so we can get feedback and start fixing things.23:17
*** dstufft has joined #openstack-sdks23:17
*** dstufft has left #openstack-sdks23:17
mordreddtroyer: ++23:17
*** shakamunyi has joined #openstack-sdks23:18
*** barra204 has joined #openstack-sdks23:18
morganfainbergOnce we cut 1.x new interfaces that break any compat is 2.x target23:18
morganfainbergIncluding anything that could be dependency changes.23:18
morganfainbergThat is why we will be ripping Oslo things out of it.23:19
morganfainbergPbr is my only real question mark.23:19
dtroyerI'll wait to look at 0.1.0 before jumping about over the dependencies ;)23:19
dtroyer(no oslo)23:19
morganfainbergYeah 0.1.0 has extra deps. But that is because we wanted the cleanup in Gerrit.23:19
dtroyernot to dis Oslo, but they're meant for servers23:20
morganfainbergNot before import to Gerrit.23:20
morganfainbergdtroyer: exactly.23:20
dtroyerok, cool.  morganfainberg I need to buy you a beer next week for calming me down, thanks23:20
morganfainbergIn fact, let me make an infra change so I can have a separate ksa core team.23:21
dtroyerI knew ksa would be small, light, etc, just not that it was planned for the SDK too23:21
morganfainbergIt'll inherit keystone but maybe someone like you is the right person to add.23:21
morganfainbergGet SDK/client focus people also weighing in.23:22
morganfainbergdtroyer: it is planned to supplant the awful mess of needing ksc to do auth.23:22
dtroyerI'd be happy to do that23:22
morganfainbergLog term, I want bindings for non-putting langs for it too.23:22
morganfainbergDamn autocorrect.23:23
morganfainbergAs soon as I am home I'll make the infra proposal change.23:23
dtroyerFWIW, I have already started re-working the existing go lib to use the session-style so things ought to translate easier23:23
morganfainbergI really want ksa to be an example of the right way to isolate specific functionality.23:23
morganfainbergdtroyer: yeah step away from the cliff. We're here to make your life better :)23:25
morganfainbergjamielennox|away: ^^ btw - see what I just committed you to? :P23:25
dtroyerI know, and thanks again.  The madness must be stopped one way or another23:26
morganfainbergSo let's take a look at pbr. We might need to ditch it for ksa23:27
morganfainbergTalk at the summit about that? Ksa will need to not be proposal bot requirements updated.23:27
dtroyerI have no opinion there unless/until the rest of the client stack doesn't need it too23:27
morganfainbergWell the issue is pbr could cause compat issues in edge cases here.23:28
morganfainbergI'll need to corner mordred and lifeless on that.23:28
morganfainbergIf we need non-pbr setup for ksa, we can do that.23:28
morganfainbergBut i want to make sure we aren't cornering ourselves in either case.23:29
mordredwe dn't need it to be a requirements requirement23:31
mordredbuild requirement is fine23:31
mordredand shouldnt' be a problem23:31
openstackgerritMerged stackforge/python-openstacksdk: Changes for database proxy gets
morganfainbergmordred: ok cool.23:33
*** sigmavirus24 is now known as sigmavirus24_awa23:33
morganfainbergI think requests and six are going to be the hard-to-avoid requirements.23:33
morganfainbergAnd argparse *glare Python 2.6*23:34
mordredmorganfainberg: why do you need argparse in keystoneauuth?23:34
mordredit's a library, not a commnad line program23:34
morganfainbergmordred: there is some option handling. Not sure. Hope to drop that too.23:34
mordreddrop it23:34
morganfainbergAll the option handling that is.23:34
mordredit's not appropriate23:34
mordredit should have a library interface that's clean23:34
morganfainbergBut it's part of the cleanup. Ideally, six and requests.23:35
morganfainbergAnd stevedore.23:35
morganfainbergFor plugins.23:35
openstackgerritMerged stackforge/python-openstacksdk: Changes for get calls in image proxies
morganfainbergThat would make me very happy.23:35
mordredmorganfainberg: thereyago: no pbr :)23:36
morganfainbergAhaha. Sounds good.23:36
*** pm90_ has quit IRC23:38
mordredmorganfainberg: otoh - argparse isn't ACTUALLY a problem since it's built in to 2.7 and beyond23:38
mordredand even the 2.6 lib has a very stable interface23:38
morganfainbergAha right.23:39
morganfainbergBut still silly to need it.23:39
openstackgerritMerged stackforge/python-openstacksdk: Changes for compute proxy list calls
dtroyerIIRC argparse was needed to do all of the oslo.config stuff that I think could be layered on top if it is still required.  I agree it doesn't belong in ksa23:43
*** pm90_ has joined #openstack-sdks23:52

Generated by 2.14.0 by Marius Gedminas - find it at!