Tuesday, 2015-05-05

*** stevemar has joined #openstack-sdks00:06
*** stevemar has quit IRC00:32
*** bradbeam has joined #openstack-sdks00:38
*** Qiming has joined #openstack-sdks00:55
*** Qiming_ has joined #openstack-sdks00:56
*** Qiming has quit IRC01:01
*** Qiming__ has joined #openstack-sdks01:01
*** Qiming_ has quit IRC01:04
*** etoews has quit IRC01:09
*** Qiming has joined #openstack-sdks01:21
*** Qiming__ has quit IRC01:24
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Fix docs for volume proxy delete  https://review.openstack.org/17999301:54
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Proxy update telemetry changes  https://review.openstack.org/17999401:54
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Proxy update network changes  https://review.openstack.org/17999501:55
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Proxy update keystore changes  https://review.openstack.org/17999601:56
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Proxy update image changes  https://review.openstack.org/17999701:56
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Proxy update identity changes  https://review.openstack.org/17999801:56
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: proxy update database changes  https://review.openstack.org/17999901:57
*** sigmavirus24 is now known as sigmavirus24_awa02:33
openstackgerritJamie Lennox proposed openstack/python-openstackclient: Don't create empty quota set requests  https://review.openstack.org/18001202:45
*** stevemar has joined #openstack-sdks03:43
jamielennoxstevemar: is there any guideline yet on what is suitable for backport for OSC03:45
stevemarjamielennox, no guideline yet, just saw your tagging of a bug03:46
jamielennoxi understand that requirements means that we have to pin things, but i want to keep delivering features throughout the kilo cycle not just bug fixes03:46
jamielennoxit would suck if the first new thing i could bring into a packaged version of OSC was after the liberty release03:46
stevemarjamielennox, oh i see what you mean03:47
jamielennoxstevemar: well that one is a legit bug that i think needs a backport03:47
jamielennoxhttps://review.openstack.org/180012 is more what i was wondering03:47
stevemarthats what i was referring to too03:48
jamielennoxso for RDO they are going to package according to the global reqs so kilo is ~>1.003:48
stevemarchanging the requirements in a stable release is a no-no right?03:48
* stevemar starts doing mental gymnastics03:49
jamielennoxbut for something like OSC there are a whole lot of fixes that don't impact reqs03:49
stevemarif it's backported we'll have to release a new kilo version too?03:49
jamielennoxyea, but dtroyer has been doing that, there's been 1.0.[123]03:49
stevemar1.0.x for kilo... and 1.1.x for liberty03:50
stevemarthat would be interesting03:50
jamielennoxhe released 1.2 the other day so no03:50
stevemardtroyer, any thoughts?03:50
dtroyerthe versions do not map to releases03:50
jamielennoxbut it would be better if there was some sort of scheme like that rather than 1.0 for kilo and 1.45 for liberty03:50
dtroyeri's only for the needs of stable that we even do this03:51
jamielennoxi didn't even consider invoking the devil - i thought you'd be asleep03:51
stevemarhe awoke from his slumber?03:51
dtroyerour (OSc) versions are not useful to follow using the traditional RDO rules03:51
stevemardoes that make me kerberos?03:51
* jamielennox can't handle another definition of kerberos - even if it is the original one 03:52
dtroyerwe pegged 1.0.3 as the 'stable' for stable CI testing, nothing else03:52
stevemari'm glad it didn't go to waste, thanks jamielennox03:52
jamielennoxdtroyer: it's not so much that RDO will track OSC stable, it's that RDO will adopt the stable/kilo global-requirements03:52
jamielennoxand that is <1.1.0 https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L12903:53
dtroyerthen RDO is stuck.  I'm not maintaining multiple branches.03:53
dtroyerthis is where the entire python packaging blows chunks03:53
jamielennoxdtroyer: completely agree03:54
dtroyerso have you looked at pex?03:54
stevemarafk for a bit03:54
jamielennoxit's a dumb issue, and for us at least the issue is that all the requirements people consider server side code and clients need different rules03:54
dtroyerif it can be made to work with cliff's entrypoint usage that's the direction I want to go03:54
jamielennoxus = OSC/KSC/etc not RDO03:55
dtroyerthey do need different rules03:55
dtroyeractually, we need to vendor all the shit03:55
dtroyerseriously, I'm reviving the Go work just because I'm sick and tired of all this03:55
jamielennoxclients should require the minimum required version, instead global-reqs bot comes around and bumps everyone up with things they don't need03:55
jamielennoxi'm not a vendoring fan03:56
dtroyerno, but pragmatism might just let us keep moving03:56
jamielennoxsad but fair03:56
dtroyerwe've been stuck in this loop for a couple of years now for 'purity'.03:57
jamielennoxdokah dokah dokah03:57
dtroyeralso, we keep bumping up the minimums because people keep fixing bugs and adding features on libs that we use ;)03:57
dtroyerso vendoring, whether shipped all in a jar file or built on-site in venvs is going to be in our future.03:58
dtroyerhow else do we let arbitrary versions of prereqs live on the same system?04:00
dtroyerthe only way out I see for OSC is to never let anything server-side use the SDK and we switch and never let client and server side share prereqs04:01
dtroyergonna such if requests does anything interesting though04:01
jamielennoxif i had an answer to that i'd be rich04:01
dtroyerpex, py2exe, et al if we dump entrypoints04:02
dtroyeralso, those are vendoring anyway ;)04:02
jamielennoxdtroyer: ok so i have two cases04:04
jamielennoxboth i posted in the last hour or two04:04
jamielennoxhttps://review.openstack.org/180012 and https://review.openstack.org/18001804:04
jamielennoxthe first is a fairly simply bug, when accepted i was going to propose it for 1.0.4 as well04:05
jamielennoxthe second backports a new-ish feature from nkinder to 1.0.404:05
dtroyeryeah, I don't see a versioning problem with 18001204:06
dtroyerdo you have a cherry-pick commit for it though?04:06
jamielennoxdtroyer: that one's new04:07
jamielennoxit get's slightly messy because that same fix for the volume options was done as a part of a different stevemar patch04:07
jamielennoxbut still it's small and we can work that out in the cherry-pick04:07
dtroyerok, I thought it looked familiar, just a reference to the mater even if not a cherry pick is fine04:08
dtroyer180018 is less clear04:08
jamielennoxexactly, that's a definite new feature and probably touches a lot of places04:09
jamielennoxthe initial review also mentions that stevemar was going to do a refactoring cleanup review that i didn't find04:09
jamielennox(didn't look that hard)04:09
dtroyerI need to think on this a bit.04:13
dtroyermy initial reaction is to push the burden of maintaining multiple branches close to the cause04:14
*** Qiming_ has joined #openstack-sdks04:15
jamielennoxdtroyer: by cause do you mean distro, or the requirements/infra people, or OSC04:15
dtroyerthe initial reason for doing stable branches was to support CI, followed closely by downstream desires04:16
dtroyerCI only needs bug fixes04:16
jamielennoxalso i agree, i was thinking on it and thought i'd come over here and ask if someone else had gotten through it04:16
dtroyerdownstram wants features04:16
dtroyerand it'll only be some features as some will have requirements that can not be met in stable04:17
dtroyerso I also don't want to maintain the documentation and feature mapping ;)04:17
dtroyersee red hat's traditional kernel maintenance model04:17
*** Qiming has quit IRC04:18
dtroyerwhich was hell for SAs who needed to always track multiple bug lists and kernel versions…we couldn't compare rhel with debian or suse easily04:19
dtroyerso there's part of my resistance, I don't want to do that to our (OSC) users04:19
dtroyerif 180018 goes in, we'll have to say that applies to 1.0.4 and 1.2.x, etc, rather than > 1.2.x04:20
dtroyerjust thinking out loud here04:20
dtroyerand after Liberty releases, we'll have potentially three branches.  Maybe for later as I don't know exactly when kilo is EOL04:21
dtroyerfor clients, I can't see that being good for anyone04:22
jamielennoxright, i have no idea how you'd figure out making sure each patch was backported correctly04:23
jamielennoxit just gets messy and pip versioning only just figured out how to use current semver problems04:23
jamielennox1.0.3 vs 1.2.0 is actually already going to give problems04:23
dtroyerthe only solution I see is functionally equivalent to vendoring, and the only difference is where the multiple prereq packages are integrated into the final package04:23
dtroyerin go, it is forced to build-time so users never see it04:24
dtroyerif we could have pex or similar working it would be similar for us too04:24
dtroyervenvs are install-time04:24
dtroyerwhether by script or rpm/deb04:24
jamielennoxi know a bit of how go's imports work, but having not used them it all makes me miss C04:25
dtroyerno, that doesn't work, it would be package-build time for both rpm and deb04:25
dtroyeryou mean putting versions into paths/filenames?04:25
dtroyerwhat a concept04:25
dtroyerso there we go, we'll start releasing everything with the major/minor in the package name04:26
dtroyerthat's how we can choose which one to use04:26
jamielennoxright, even why can't we install multiple versions of an egg side by side and have the app tell us what it needs04:26
jamielennoxthen rpm management can figure out cleaning up the old ones as it goes along04:26
dtroyerdo you know anything about conda?04:26
dtroyerI just know it exists04:26
dtroyerI wonder if they solved this yet?04:27
dtroyerwouldn't that go over well? ;)04:27
dtroyerha!  that's the whole reason it exists!  http://www.continuum.io/blog/conda04:28
dtroyerwhy didn't I read this earlier?04:28
dtroyerso if I added this to devstack instead of the venv bs… who would soot me?04:29
jamielennoxprobably everyone04:31
jamielennoxi have no idea how supported conda is04:32
dtroyerso it might just be a slightly smarter venv with local package versioning…and probably has the same issues with entrypoints04:32
jamielennoxstill reading that blog, if you are only talking devstack then it actually seems like the right idea04:33
dtroyerI don't see anything better for OSC and distribution04:34
dtroyer'better' meaning 'reason to use conda (yet)'04:34
jamielennoxwell you can't enforce these things on distributions anyway04:34
jamielennoxdoesn't seem like it's packaged for fedora04:35
dtroyerok,I gotta stop for the night, this will keep me awake if I don't04:36
jamielennoxdtroyer: ok, night - i will look into the RDO side some more, i must be wrong on this packaging thing04:37
jamielennoxthey can't limit it to stable global-reqs04:37
*** Qiming__ has joined #openstack-sdks05:28
*** Qiming_ has quit IRC05:31
*** Qiming__ has quit IRC05:52
*** Qiming__ has joined #openstack-sdks05:52
openstackgerritOpenStack Proposal Bot proposed openstack/python-openstackclient: Imported Translations from Transifex  https://review.openstack.org/17955806:06
*** Qiming__ is now known as Qiming06:22
*** openstackgerrit has quit IRC06:23
*** openstackgerrit has joined #openstack-sdks06:23
*** aufi has joined #openstack-sdks07:17
*** stevemar has quit IRC07:22
*** chlong has quit IRC07:44
*** Qiming has quit IRC09:50
*** f13o has joined #openstack-sdks09:58
*** f13o has quit IRC10:15
ekarlsodoes openstackclient use the openstacksdk ?10:28
*** Qiming has joined #openstack-sdks11:38
*** thrash|g0ne is now known as thrash11:38
*** thrash has quit IRC12:09
*** thrash has joined #openstack-sdks12:11
*** trown|outttypeww is now known as trown12:19
*** Qiming_ has joined #openstack-sdks12:37
*** Qiming has quit IRC12:40
dtroyerekarlso: not yet12:55
*** bradbeam has left #openstack-sdks12:55
*** bknudson has joined #openstack-sdks13:26
*** jaosorior has joined #openstack-sdks13:35
*** sigmavirus24_awa is now known as sigmavirus2414:03
*** joesavak has joined #openstack-sdks14:04
*** pm90_ has joined #openstack-sdks14:10
*** pm90_ has quit IRC14:12
*** pm90_ has joined #openstack-sdks14:13
*** aufi has quit IRC14:32
*** mattfarina has joined #openstack-sdks14:36
*** pm90__ has joined #openstack-sdks14:37
*** pm90__ has quit IRC14:37
*** pm90_ has quit IRC14:38
*** pm90_ has joined #openstack-sdks14:38
*** Qiming_ has quit IRC14:39
*** mattfarina has quit IRC14:55
*** mattfarina has joined #openstack-sdks14:55
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Add os-client-config support for examples  https://review.openstack.org/17966415:31
*** Daviey has joined #openstack-sdks15:46
*** chlong has joined #openstack-sdks16:00
*** bknudson has quit IRC16:14
*** chlong has quit IRC16:18
*** bradbeam has joined #openstack-sdks16:18
*** bradbeam has quit IRC16:24
openstackgerritTerry Howe proposed stackforge/python-openstacksdk: Add some examples documentation  https://review.openstack.org/18022216:26
*** jlibosva has joined #openstack-sdks16:27
dhellmannhi, jlibosva16:27
dhellmannso you're running into an issue with the default output encoding handling for cliff-based apps run in a pipeline?16:28
jlibosvayes, I think it relates to the thing that cliff doesn't encode when using non-stdout stdout :)16:28
jlibosvalike pipe or maybe theoretically file16:28
jlibosvaI'm talking about this piece of code16:29
dhellmannjlibosva: you mean "non-tty stdout"16:29
dhellmannwhat encoding do you get, in that case?16:29
jlibosvahmm, I don't know. I see ascii codec failure16:30
dhellmannah, so ascii16:30
dhellmannwhich version of python?16:31
dhellmannI would have to look at how python 2 handles default encoding for apps not connected to a tty16:31
jlibosvanote that there was an issue with py26 - https://github.com/dreamhost/cliff/commit/ba73f3f2c5b0a86ef302561b89d5db9ff4139e1a16:32
jlibosvait had special treating due to python bug https://hg.python.org/cpython/rev/e60ef17561dc/16:32
dhellmannjlibosva: do you have LOCALE set?16:33
jlibosvadhellmann: you mean LC_ALL?16:33
jlibosvaor exactly LOCALE?16:33
dhellmannLC_ALL, I guess16:33
jlibosvaI don't16:33
dhellmanndoes it work as you expect with that set?16:33
jlibosvait doesn't16:34
*** chlong has joined #openstack-sdks16:34
dhellmannjlibosva: so if you have non-ascii data it prints to the terminal correctly but it does not work in a pipeline?16:37
jlibosvadhellmann: right16:37
dhellmannjlibosva: ok, I'll have to look into why that would be. Would you file a bug against cliff with these details, please?16:39
*** chlong has quit IRC16:39
dhellmannjlibosva: I'll need a little time to research the default handling of output encoding16:39
jlibosvadhellmann: sure. I tested so far with table formatter only16:39
jlibosvadhellmann: thanks!16:39
*** joesavak has quit IRC16:40
jlibosvadhellmann: so - with json format it doesn't print error but seems like output is in unicode or what's \u0161pa\u010dek16:44
*** pm90_ has quit IRC16:45
*** mattfarina has quit IRC16:57
*** mattfarina has joined #openstack-sdks16:57
*** mattfarina has quit IRC16:57
dhellmannjlibosva: yes, that's an encoded version of the string17:01
jlibosvadhellmann: I can see that encoding is set to None on fileobject if I use pipe17:03
*** joesavak has joined #openstack-sdks17:03
-openstackstatus- NOTICE: zuul has been restarted to troubleshoot an issue, gerrit events between 15:00-17:00 utc were lost and changes updated or approved during that time will need to be rechecked or have their approval votes readded to trigger testing17:04
jlibosvabut if I do it just with python, it works17:05
jlibosvaignore the None, it's because I put print there ...17:08
*** trown is now known as trown|lunch17:29
*** jsavak has joined #openstack-sdks17:43
*** joesavak has quit IRC17:46
*** pm90_ has joined #openstack-sdks17:53
*** jlibosva has quit IRC17:59
*** joesavak has joined #openstack-sdks18:00
*** bknudson has joined #openstack-sdks18:00
*** jsavak has quit IRC18:02
*** barra204 has joined #openstack-sdks18:12
*** barra204 has quit IRC18:27
*** jsavak has joined #openstack-sdks18:29
*** joesavak has quit IRC18:32
*** barra204 has joined #openstack-sdks18:41
briancurtinFYI: i don't think a meeting is necessary for SDK today (scheduled in 10 min) and would probably just talk about reviews when instead we could just do reviews. also iirc terry is traveling and i haven't seen him on IRC yet anyway18:50
stevellesounds good18:53
*** trown|lunch is now known as trown18:57
*** bknudson has quit IRC19:00
*** subscope_ has joined #openstack-sdks19:27
*** etoews has joined #openstack-sdks19:57
*** pm90_ has quit IRC20:17
openstackgerritMonty Taylor proposed openstack/os-client-config: Also accept .yml as a suffix  https://review.openstack.org/18030620:29
*** barra204 has quit IRC20:37
*** jsavak has quit IRC21:06
*** boris-42 has quit IRC21:28
*** trown is now known as trown|outttypeww21:34
*** stevemar has joined #openstack-sdks21:47
*** bnemec has quit IRC22:05
*** bnemec has joined #openstack-sdks22:08
*** thrash is now known as thrash|g0ne22:11
*** stevemar has quit IRC22:24
*** subscope_ has quit IRC22:34
*** jaosorior has quit IRC23:32
*** chlong has joined #openstack-sdks23:37

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!