| *** stevemar has joined #openstack-sdks | 00:06 | |
| *** stevemar has quit IRC | 00:32 | |
| *** bradbeam has joined #openstack-sdks | 00:38 | |
| *** Qiming has joined #openstack-sdks | 00:55 | |
| *** Qiming_ has joined #openstack-sdks | 00:56 | |
| *** Qiming has quit IRC | 01:01 | |
| *** Qiming__ has joined #openstack-sdks | 01:01 | |
| *** Qiming_ has quit IRC | 01:04 | |
| *** etoews has quit IRC | 01:09 | |
| *** Qiming has joined #openstack-sdks | 01:21 | |
| *** Qiming__ has quit IRC | 01:24 | |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Fix docs for volume proxy delete https://review.openstack.org/179993 | 01:54 |
|---|---|---|
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Proxy update telemetry changes https://review.openstack.org/179994 | 01:54 |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Proxy update network changes https://review.openstack.org/179995 | 01:55 |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Proxy update keystore changes https://review.openstack.org/179996 | 01:56 |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Proxy update image changes https://review.openstack.org/179997 | 01:56 |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Proxy update identity changes https://review.openstack.org/179998 | 01:56 |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: proxy update database changes https://review.openstack.org/179999 | 01:57 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 02:33 | |
| openstackgerrit | Jamie Lennox proposed openstack/python-openstackclient: Don't create empty quota set requests https://review.openstack.org/180012 | 02:45 |
| *** stevemar has joined #openstack-sdks | 03:43 | |
| jamielennox | stevemar: is there any guideline yet on what is suitable for backport for OSC | 03:45 |
| stevemar | jamielennox, no guideline yet, just saw your tagging of a bug | 03:46 |
| jamielennox | i understand that requirements means that we have to pin things, but i want to keep delivering features throughout the kilo cycle not just bug fixes | 03:46 |
| jamielennox | it would suck if the first new thing i could bring into a packaged version of OSC was after the liberty release | 03:46 |
| stevemar | jamielennox, oh i see what you mean | 03:47 |
| jamielennox | stevemar: well that one is a legit bug that i think needs a backport | 03:47 |
| jamielennox | https://review.openstack.org/180012 is more what i was wondering | 03:47 |
| stevemar | thats what i was referring to too | 03:48 |
| jamielennox | so for RDO they are going to package according to the global reqs so kilo is ~>1.0 | 03:48 |
| stevemar | changing the requirements in a stable release is a no-no right? | 03:48 |
| jamielennox | yea | 03:48 |
| * stevemar starts doing mental gymnastics | 03:49 | |
| jamielennox | but for something like OSC there are a whole lot of fixes that don't impact reqs | 03:49 |
| stevemar | if it's backported we'll have to release a new kilo version too? | 03:49 |
| jamielennox | yea, but dtroyer has been doing that, there's been 1.0.[123] | 03:49 |
| stevemar | 1.0.x for kilo... and 1.1.x for liberty | 03:50 |
| stevemar | that would be interesting | 03:50 |
| jamielennox | he released 1.2 the other day so no | 03:50 |
| stevemar | yep | 03:50 |
| stevemar | dtroyer, any thoughts? | 03:50 |
| dtroyer | the versions do not map to releases | 03:50 |
| jamielennox | but it would be better if there was some sort of scheme like that rather than 1.0 for kilo and 1.45 for liberty | 03:50 |
| dtroyer | i's only for the needs of stable that we even do this | 03:51 |
| jamielennox | i didn't even consider invoking the devil - i thought you'd be asleep | 03:51 |
| stevemar | he awoke from his slumber? | 03:51 |
| dtroyer | our (OSc) versions are not useful to follow using the traditional RDO rules | 03:51 |
| stevemar | does that make me kerberos? | 03:51 |
| * jamielennox can't handle another definition of kerberos - even if it is the original one | 03:52 | |
| dtroyer | we pegged 1.0.3 as the 'stable' for stable CI testing, nothing else | 03:52 |
| stevemar | hehe | 03:52 |
| stevemar | i'm glad it didn't go to waste, thanks jamielennox | 03:52 |
| jamielennox | dtroyer: it's not so much that RDO will track OSC stable, it's that RDO will adopt the stable/kilo global-requirements | 03:52 |
| jamielennox | and that is <1.1.0 https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L129 | 03:53 |
| dtroyer | then RDO is stuck. I'm not maintaining multiple branches. | 03:53 |
| dtroyer | this is where the entire python packaging blows chunks | 03:53 |
| jamielennox | dtroyer: completely agree | 03:54 |
| dtroyer | so have you looked at pex? | 03:54 |
| stevemar | afk for a bit | 03:54 |
| jamielennox | it'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 rules | 03:54 |
| dtroyer | if it can be made to work with cliff's entrypoint usage that's the direction I want to go | 03:54 |
| jamielennox | us = OSC/KSC/etc not RDO | 03:55 |
| dtroyer | they do need different rules | 03:55 |
| dtroyer | actually, we need to vendor all the shit | 03:55 |
| dtroyer | seriously, I'm reviving the Go work just because I'm sick and tired of all this | 03:55 |
| jamielennox | clients should require the minimum required version, instead global-reqs bot comes around and bumps everyone up with things they don't need | 03:55 |
| jamielennox | i'm not a vendoring fan | 03:56 |
| dtroyer | no, but pragmatism might just let us keep moving | 03:56 |
| jamielennox | sad but fair | 03:56 |
| dtroyer | we've been stuck in this loop for a couple of years now for 'purity'. | 03:57 |
| jamielennox | dokah dokah dokah | 03:57 |
| dtroyer | also, we keep bumping up the minimums because people keep fixing bugs and adding features on libs that we use ;) | 03:57 |
| dtroyer | so vendoring, whether shipped all in a jar file or built on-site in venvs is going to be in our future. | 03:58 |
| dtroyer | how else do we let arbitrary versions of prereqs live on the same system? | 04:00 |
| dtroyer | the 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 prereqs | 04:01 |
| dtroyer | gonna such if requests does anything interesting though | 04:01 |
| jamielennox | if i had an answer to that i'd be rich | 04:01 |
| dtroyer | pex, py2exe, et al if we dump entrypoints | 04:02 |
| dtroyer | also, those are vendoring anyway ;) | 04:02 |
| jamielennox | dtroyer: ok so i have two cases | 04:04 |
| jamielennox | both i posted in the last hour or two | 04:04 |
| jamielennox | https://review.openstack.org/180012 and https://review.openstack.org/180018 | 04:04 |
| jamielennox | the first is a fairly simply bug, when accepted i was going to propose it for 1.0.4 as well | 04:05 |
| jamielennox | the second backports a new-ish feature from nkinder to 1.0.4 | 04:05 |
| dtroyer | yeah, I don't see a versioning problem with 180012 | 04:06 |
| dtroyer | do you have a cherry-pick commit for it though? | 04:06 |
| jamielennox | dtroyer: that one's new | 04:07 |
| jamielennox | it get's slightly messy because that same fix for the volume options was done as a part of a different stevemar patch | 04:07 |
| jamielennox | but still it's small and we can work that out in the cherry-pick | 04:07 |
| dtroyer | ok, I thought it looked familiar, just a reference to the mater even if not a cherry pick is fine | 04:08 |
| dtroyer | 180018 is less clear | 04:08 |
| jamielennox | exactly, that's a definite new feature and probably touches a lot of places | 04:09 |
| jamielennox | the initial review also mentions that stevemar was going to do a refactoring cleanup review that i didn't find | 04:09 |
| jamielennox | (didn't look that hard) | 04:09 |
| dtroyer | I need to think on this a bit. | 04:13 |
| dtroyer | my initial reaction is to push the burden of maintaining multiple branches close to the cause | 04:14 |
| *** Qiming_ has joined #openstack-sdks | 04:15 | |
| jamielennox | dtroyer: by cause do you mean distro, or the requirements/infra people, or OSC | 04:15 |
| dtroyer | the initial reason for doing stable branches was to support CI, followed closely by downstream desires | 04:16 |
| dtroyer | CI only needs bug fixes | 04:16 |
| jamielennox | also i agree, i was thinking on it and thought i'd come over here and ask if someone else had gotten through it | 04:16 |
| dtroyer | downstram wants features | 04:16 |
| dtroyer | and it'll only be some features as some will have requirements that can not be met in stable | 04:17 |
| dtroyer | so I also don't want to maintain the documentation and feature mapping ;) | 04:17 |
| dtroyer | see red hat's traditional kernel maintenance model | 04:17 |
| *** Qiming has quit IRC | 04:18 | |
| dtroyer | which was hell for SAs who needed to always track multiple bug lists and kernel versions…we couldn't compare rhel with debian or suse easily | 04:19 |
| dtroyer | so there's part of my resistance, I don't want to do that to our (OSC) users | 04:19 |
| dtroyer | if 180018 goes in, we'll have to say that applies to 1.0.4 and 1.2.x, etc, rather than > 1.2.x | 04:20 |
| dtroyer | just thinking out loud here | 04:20 |
| dtroyer | and after Liberty releases, we'll have potentially three branches. Maybe for later as I don't know exactly when kilo is EOL | 04:21 |
| dtroyer | s/for/four/ | 04:21 |
| dtroyer | for clients, I can't see that being good for anyone | 04:22 |
| jamielennox | right, i have no idea how you'd figure out making sure each patch was backported correctly | 04:23 |
| jamielennox | it just gets messy and pip versioning only just figured out how to use current semver problems | 04:23 |
| jamielennox | 1.0.3 vs 1.2.0 is actually already going to give problems | 04:23 |
| dtroyer | the only solution I see is functionally equivalent to vendoring, and the only difference is where the multiple prereq packages are integrated into the final package | 04:23 |
| dtroyer | in go, it is forced to build-time so users never see it | 04:24 |
| dtroyer | if we could have pex or similar working it would be similar for us too | 04:24 |
| dtroyer | venvs are install-time | 04:24 |
| dtroyer | whether by script or rpm/deb | 04:24 |
| jamielennox | i know a bit of how go's imports work, but having not used them it all makes me miss C | 04:25 |
| dtroyer | no, that doesn't work, it would be package-build time for both rpm and deb | 04:25 |
| dtroyer | you mean putting versions into paths/filenames? | 04:25 |
| dtroyer | what a concept | 04:25 |
| dtroyer | so there we go, we'll start releasing everything with the major/minor in the package name | 04:26 |
| dtroyer | that's how we can choose which one to use | 04:26 |
| jamielennox | right, even why can't we install multiple versions of an egg side by side and have the app tell us what it needs | 04:26 |
| jamielennox | then rpm management can figure out cleaning up the old ones as it goes along | 04:26 |
| dtroyer | do you know anything about conda? | 04:26 |
| dtroyer | I just know it exists | 04:26 |
| dtroyer | I wonder if they solved this yet? | 04:27 |
| dtroyer | wouldn't that go over well? ;) | 04:27 |
| dtroyer | ha! that's the whole reason it exists! http://www.continuum.io/blog/conda | 04:28 |
| dtroyer | why didn't I read this earlier? | 04:28 |
| dtroyer | so if I added this to devstack instead of the venv bs… who would soot me? | 04:29 |
| jamielennox | probably everyone | 04:31 |
| jamielennox | i have no idea how supported conda is | 04:32 |
| dtroyer | so it might just be a slightly smarter venv with local package versioning…and probably has the same issues with entrypoints | 04:32 |
| dtroyer | damn | 04:33 |
| jamielennox | still reading that blog, if you are only talking devstack then it actually seems like the right idea | 04:33 |
| dtroyer | I don't see anything better for OSC and distribution | 04:34 |
| dtroyer | 'better' meaning 'reason to use conda (yet)' | 04:34 |
| jamielennox | well you can't enforce these things on distributions anyway | 04:34 |
| jamielennox | doesn't seem like it's packaged for fedora | 04:35 |
| dtroyer | ok,I gotta stop for the night, this will keep me awake if I don't | 04:36 |
| jamielennox | dtroyer: ok, night - i will look into the RDO side some more, i must be wrong on this packaging thing | 04:37 |
| jamielennox | they can't limit it to stable global-reqs | 04:37 |
| *** Qiming__ has joined #openstack-sdks | 05:28 | |
| *** Qiming_ has quit IRC | 05:31 | |
| *** Qiming__ has quit IRC | 05:52 | |
| *** Qiming__ has joined #openstack-sdks | 05:52 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient: Imported Translations from Transifex https://review.openstack.org/179558 | 06:06 |
| *** Qiming__ is now known as Qiming | 06:22 | |
| *** openstackgerrit has quit IRC | 06:23 | |
| *** openstackgerrit has joined #openstack-sdks | 06:23 | |
| *** aufi has joined #openstack-sdks | 07:17 | |
| *** stevemar has quit IRC | 07:22 | |
| *** chlong has quit IRC | 07:44 | |
| *** Qiming has quit IRC | 09:50 | |
| *** f13o has joined #openstack-sdks | 09:58 | |
| *** f13o has quit IRC | 10:15 | |
| ekarlso | does openstackclient use the openstacksdk ? | 10:28 |
| *** Qiming has joined #openstack-sdks | 11:38 | |
| *** thrash|g0ne is now known as thrash | 11:38 | |
| *** thrash has quit IRC | 12:09 | |
| *** thrash has joined #openstack-sdks | 12:11 | |
| *** trown|outttypeww is now known as trown | 12:19 | |
| *** Qiming_ has joined #openstack-sdks | 12:37 | |
| *** Qiming has quit IRC | 12:40 | |
| dtroyer | ekarlso: not yet | 12:55 |
| *** bradbeam has left #openstack-sdks | 12:55 | |
| *** bknudson has joined #openstack-sdks | 13:26 | |
| *** jaosorior has joined #openstack-sdks | 13:35 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:03 | |
| *** joesavak has joined #openstack-sdks | 14:04 | |
| *** pm90_ has joined #openstack-sdks | 14:10 | |
| *** pm90_ has quit IRC | 14:12 | |
| *** pm90_ has joined #openstack-sdks | 14:13 | |
| *** aufi has quit IRC | 14:32 | |
| *** mattfarina has joined #openstack-sdks | 14:36 | |
| *** pm90__ has joined #openstack-sdks | 14:37 | |
| *** pm90__ has quit IRC | 14:37 | |
| *** pm90_ has quit IRC | 14:38 | |
| *** pm90_ has joined #openstack-sdks | 14:38 | |
| *** Qiming_ has quit IRC | 14:39 | |
| *** mattfarina has quit IRC | 14:55 | |
| *** mattfarina has joined #openstack-sdks | 14:55 | |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Add os-client-config support for examples https://review.openstack.org/179664 | 15:31 |
| *** Daviey has joined #openstack-sdks | 15:46 | |
| *** chlong has joined #openstack-sdks | 16:00 | |
| *** bknudson has quit IRC | 16:14 | |
| *** chlong has quit IRC | 16:18 | |
| *** bradbeam has joined #openstack-sdks | 16:18 | |
| *** bradbeam has quit IRC | 16:24 | |
| openstackgerrit | Terry Howe proposed stackforge/python-openstacksdk: Add some examples documentation https://review.openstack.org/180222 | 16:26 |
| *** jlibosva has joined #openstack-sdks | 16:27 | |
| dhellmann | hi, jlibosva | 16:27 |
| jlibosva | hello | 16:27 |
| dhellmann | so you're running into an issue with the default output encoding handling for cliff-based apps run in a pipeline? | 16:28 |
| jlibosva | yes, I think it relates to the thing that cliff doesn't encode when using non-stdout stdout :) | 16:28 |
| jlibosva | like pipe or maybe theoretically file | 16:28 |
| jlibosva | I'm talking about this piece of code | 16:29 |
| jlibosva | http://git.openstack.org/cgit/openstack/cliff/tree/cliff/app.py#n103 | 16:29 |
| dhellmann | jlibosva: you mean "non-tty stdout" | 16:29 |
| dhellmann | what encoding do you get, in that case? | 16:29 |
| jlibosva | hmm, I don't know. I see ascii codec failure | 16:30 |
| dhellmann | ah, so ascii | 16:30 |
| dhellmann | which version of python? | 16:31 |
| jlibosva | 2.7.8 | 16:31 |
| dhellmann | I would have to look at how python 2 handles default encoding for apps not connected to a tty | 16:31 |
| jlibosva | note that there was an issue with py26 - https://github.com/dreamhost/cliff/commit/ba73f3f2c5b0a86ef302561b89d5db9ff4139e1a | 16:32 |
| jlibosva | it had special treating due to python bug https://hg.python.org/cpython/rev/e60ef17561dc/ | 16:32 |
| dhellmann | jlibosva: do you have LOCALE set? | 16:33 |
| jlibosva | dhellmann: you mean LC_ALL? | 16:33 |
| jlibosva | or exactly LOCALE? | 16:33 |
| dhellmann | LC_ALL, I guess | 16:33 |
| jlibosva | I don't | 16:33 |
| dhellmann | does it work as you expect with that set? | 16:33 |
| jlibosva | it doesn't | 16:34 |
| *** chlong has joined #openstack-sdks | 16:34 | |
| dhellmann | jlibosva: so if you have non-ascii data it prints to the terminal correctly but it does not work in a pipeline? | 16:37 |
| jlibosva | dhellmann: right | 16:37 |
| dhellmann | jlibosva: 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 IRC | 16:39 | |
| dhellmann | jlibosva: I'll need a little time to research the default handling of output encoding | 16:39 |
| jlibosva | dhellmann: sure. I tested so far with table formatter only | 16:39 |
| jlibosva | dhellmann: thanks! | 16:39 |
| *** joesavak has quit IRC | 16:40 | |
| jlibosva | dhellmann: so - with json format it doesn't print error but seems like output is in unicode or what's \u0161pa\u010dek | 16:44 |
| *** pm90_ has quit IRC | 16:45 | |
| *** mattfarina has quit IRC | 16:57 | |
| *** mattfarina has joined #openstack-sdks | 16:57 | |
| *** mattfarina has quit IRC | 16:57 | |
| dhellmann | jlibosva: yes, that's an encoded version of the string | 17:01 |
| jlibosva | dhellmann: I can see that encoding is set to None on fileobject if I use pipe | 17:03 |
| *** joesavak has joined #openstack-sdks | 17: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 testing | 17:04 | |
| jlibosva | but if I do it just with python, it works | 17:05 |
| jlibosva | http://paste.openstack.org/show/215021/ | 17:06 |
| jlibosva | ignore the None, it's because I put print there ... | 17:08 |
| *** trown is now known as trown|lunch | 17:29 | |
| *** jsavak has joined #openstack-sdks | 17:43 | |
| *** joesavak has quit IRC | 17:46 | |
| *** pm90_ has joined #openstack-sdks | 17:53 | |
| *** jlibosva has quit IRC | 17:59 | |
| *** joesavak has joined #openstack-sdks | 18:00 | |
| *** bknudson has joined #openstack-sdks | 18:00 | |
| *** jsavak has quit IRC | 18:02 | |
| *** barra204 has joined #openstack-sdks | 18:12 | |
| *** barra204 has quit IRC | 18:27 | |
| *** jsavak has joined #openstack-sdks | 18:29 | |
| *** joesavak has quit IRC | 18:32 | |
| *** barra204 has joined #openstack-sdks | 18:41 | |
| briancurtin | FYI: 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 anyway | 18:50 |
| stevelle | sounds good | 18:53 |
| *** trown|lunch is now known as trown | 18:57 | |
| *** bknudson has quit IRC | 19:00 | |
| *** subscope_ has joined #openstack-sdks | 19:27 | |
| *** etoews has joined #openstack-sdks | 19:57 | |
| *** pm90_ has quit IRC | 20:17 | |
| openstackgerrit | Monty Taylor proposed openstack/os-client-config: Also accept .yml as a suffix https://review.openstack.org/180306 | 20:29 |
| *** barra204 has quit IRC | 20:37 | |
| *** jsavak has quit IRC | 21:06 | |
| *** boris-42 has quit IRC | 21:28 | |
| *** trown is now known as trown|outttypeww | 21:34 | |
| *** stevemar has joined #openstack-sdks | 21:47 | |
| *** bnemec has quit IRC | 22:05 | |
| *** bnemec has joined #openstack-sdks | 22:08 | |
| *** thrash is now known as thrash|g0ne | 22:11 | |
| *** stevemar has quit IRC | 22:24 | |
| *** subscope_ has quit IRC | 22:34 | |
| *** jaosorior has quit IRC | 23:32 | |
| *** chlong has joined #openstack-sdks | 23:37 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!