| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-12 | |||
| 21:02:26 | dtroyer | like we don't publish anything other than docs, the final release is really just the tags in git. but the docs… whee! I'm learning a LOT | |
| 21:02:44 | smcginnis | Heh, yeah. I think it's sprinkled everywhere assuming stable/ | |
| 21:03:29 | dtroyer | I'm trying to decide if it is too late to change. Maybe for this release it is but it's also basically an alpha release. MAybe for the one in MArch we will change it… | |
| 21:04:23 | smcginnis | You may end up having changed enough by that point not to, but if we ever think there may be some convergence point in the future between these, it might make sense to try to stay with stable. | |
| 21:04:34 | smcginnis | Not sure if that's a realistic thing or not. | |
| 21:05:07 | smcginnis | But at least picking up future release automation changes from openstack, it might make it easier if there's less to tweak in adopting it. | |
| 21:06:48 | dtroyer | honestly the convergence I see is possibly taking a project or two and making them look even more like OpenStack projects, they might be useful for your average Joe Cloud too… | |
| 21:07:23 | smcginnis | Yeah, hopefully that's the case. | |
| 21:07:28 | dtroyer | I am stealing^H^H^H^Hborrowing as much as I can, thanks for all the fish! | |
| 21:08:50 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add stackviz processing to functional tests https://review.openstack.org/610167 | |
| 21:15:08 | smcginnis | I would definitely do the same. | |
| 21:22:25 | samueldmq | hi, is there a description of what each one of SDK's gate jobs does? | |
| 21:22:28 | samueldmq | mordred: ^ | |
| 21:23:13 | samueldmq | it's not too hard to have an idea with the job name, but I was wondering if I could confirm that somehow | |
| 21:37:05 | openstackgerrit | Merged openstack/os-client-config master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610051 | |
| 21:39:47 | smcginnis | samueldmq: You should be able to take a look at the logs to see what commands the jobs are running. | |
| 21:40:00 | smcginnis | samueldmq: Or search for the job name in codesearch.openstack.org to track down its definition. | |
| 22:41:42 | openstackgerrit | Merged openstack/python-openstackclient master: Add volume backend capability show command https://review.openstack.org/609122 | |
| 22:41:44 | openstackgerrit | Merged openstack/python-openstackclient master: Add volume backend pool list command https://review.openstack.org/608740 | |
| 22:41:47 | openstackgerrit | Merged openstack/python-openstackclient master: Allow endpoint filtering on both project and project-domain https://review.openstack.org/608912 | |
| 23:19:31 | samueldmq | smcginnis: Awesome. Thanks | |
| #openstack-sdks - 2018-10-13 | |||
| 12:15:13 | openstackgerrit | Andreas Jaeger proposed openstack/osc-lib master: Do not merge: Testing legacy-tempest-dsvm-neutron-src https://review.openstack.org/610242 | |
| 12:38:11 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add stackviz processing to functional tests https://review.openstack.org/610167 | |
| 12:46:03 | mordred | samueldmq, smcginnis: we just landed zuul dashboard support for web pages for each job. so, for instance, http://zuul.openstack.org/job/openstacksdk-functional-devstack | |
| 12:46:36 | mordred | samueldmq: it would not be a bad idea to add more explanation into the description fields of our jobs though | |
| 12:48:45 | samueldmq | mordred: that's awesome. infra team always doing a great job | |
| 12:49:32 | samueldmq | mordred: and I agree having a better description would be nice, specially for newcomer willing to understand what we test | |
| 12:49:36 | mordred | ++ | |
| 12:50:00 | mordred | like, if you go up the stack a bit, you hit http://zuul.openstack.org/job/devstack-tox-functional - which has a much more verbose description :) | |
| 12:50:02 | samueldmq | mordred: btw why do we need a neutron-grenade job? | |
| 12:51:01 | mordred | because openstacksdk is used in openstackclient which is used in devstack - so we have to make sure patches to openstacksdk don't break the entire gate for everybody :) | |
| 12:51:49 | samueldmq | mordred: aha that's cool. I'm documenting that too | |
| 12:52:19 | samueldmq | if a broken release goes out and is adopted by the ci system. you break the whole openstack ci | |
| 12:52:20 | mordred | awesome | |
| 12:52:26 | mordred | yah | |
| 12:52:42 | mordred | now - to be fair - we'd eventually catch that when trying to raise the constraints | |
| 12:52:56 | samueldmq | great powers, great responsibility | |
| 12:53:05 | mordred | but yeah - exactly | |
| 12:53:08 | mordred | better safe than sorry | |
| 12:53:13 | samueldmq | mordred: is there a test first thing for raising contraints? | |
| 12:53:24 | mordred | there is | |
| 12:53:42 | mordred | a patch gets submitted to openstack/requirements raising the constraints, and that runs devstack jobs too | |
| 12:54:03 | samueldmq | awesome. ci in openstack is quite impressive | |
| 12:54:06 | mordred | \o/ | |
| 12:54:16 | samueldmq | :D | |
| 13:56:51 | openstackgerrit | Merged openstack/openstacksdk master: Fix list_recordsets to deal with top-level key https://review.openstack.org/600441 | |
| 15:35:15 | mnaser | mordred: in my triaging ... https://github.com/ansible/ansible/issues/36286 seems like a REALLY weird bug | |
| 15:37:32 | mnaser | i dunno.. it doesnt make sense that shade would do that | |
| 15:37:39 | mnaser | but maybe there is behaviour that does that? | |
| 15:42:50 | mordred | mnaser: I can't think of any - that's super strange | |
| 15:44:14 | mnaser | mordred: yeah.. weird :\ | |
| 15:44:23 | mnaser | i wonder if like somehow ansible is filtering things | |
| 16:29:13 | mnaser | mordred: do you know if ansible modules has a 'rule' of supporting a certain range of openstack clouds? | |
| 16:29:33 | mnaser | i.e. https://github.com/ansible/ansible/issues/24786 seems to be probably because it's against a kilo deployment | |
| 16:29:45 | mnaser | so not sure if there's some "we aim to support X openstack releases" | |
| 21:52:08 | mordred | mnaser: the general support policy is mostly based on that of openstacksdk - which is "all of them" | |
| 21:52:36 | mnaser | mordred: ok cool, ran into a few fun ones earlier and didnt want to say "but you're running kilo..." | |
| 21:53:40 | mordred | mnaser: yah - I mean, sometimes it's tough to get enough debugging info to figure out why it's not working - and I imagine that the discovery code is only going to expose more bugs like that | |
| 21:54:28 | mnaser | mordred: sometimes it's just openstacksdk changes for API changes in $service that were done a long time ago with no backwards compatible fixes | |
| 21:54:36 | mnaser | mainly because no one thought of going all the way back to kilo to check if it worked then | |
| 22:02:40 | mordred | mnaser: yah - and our requests-mock unit tests are more recent | |
| 22:03:12 | mordred | it's super easy to maintain compat with older versions if we have a requests-mock test for a thing | |
| 22:04:24 | mnaser | yeah, way easier than deploy devstack for kilo :) | |
| #openstack-sdks - 2018-10-14 | |||
| 12:28:45 | mordred | Shrews, dtantsur: check it out: http://logs.openstack.org/67/610167/2/check/openstacksdk-functional-devstack/fd6abf6/controller/logs/stackviz/#/stdin/timeline -- I added the stackvix post-processing role https://review.openstack.org/#/c/610167/ | |
| #openstack-sdks - 2018-10-15 | |||
| 01:34:10 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Add registered limit CRUD support https://review.openstack.org/609572 | |
| 01:34:17 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Add limit CRUD support https://review.openstack.org/609604 | |
| 01:36:10 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Add registered limit CRUD support https://review.openstack.org/609572 | |
| 01:36:11 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Add limit CRUD support https://review.openstack.org/609604 | |
| 03:01:11 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Add registered limit CRUD support https://review.openstack.org/609572 | |
| 03:01:12 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Add limit CRUD support https://review.openstack.org/609604 | |
| 03:06:01 | openstackgerrit | wangxiyuan proposed openstack/openstacksdk master: Remove duplicate code https://review.openstack.org/610404 | |
| 09:41:04 | dtantsur | mordred: impressive! | |
| 10:13:07 | samueldmq | morning | |
| 10:13:56 | samueldmq | does recall if there was ever a version 1 of keystone, nova and neutron? | |
| 10:14:10 | samueldmq | I suspect there was but only in the first days of openstack. I don't remember why we chose to jump to 2.0 on all those.. | |
| 10:14:58 | samueldmq | mordred: ^ I know you were here since the first days ... so you might know somehting about thsi | |
| 10:22:10 | frickler | samueldmq: this has a bit of history for keystone https://docs.openstack.org/keystone/pike/contributor/http-api.html#history . I'm also pretty sure neutron only ever implemented v2, but I can only guess that that happened in order to match nova when it was split out | |
| 10:24:12 | frickler | samueldmq: and this makes me assume that nova v1 was also the legacy rackspace api https://blueprints.launchpad.net/openstack-sdk-php/+spec/nova-api-v1 | |
| 10:37:35 | samueldmq | Hmm. Awesome | |
| 10:37:54 | samueldmq | Thanks frickler | |
| 11:10:13 | dtantsur | frickler++ this is interesting | |
| 13:18:40 | mordred | frickler: yes - nova v1 was the legacy rackspace api ... keystone v1 was, iirc, the legacy rackspace auth | |
| 13:18:55 | mordred | ah - yes, that link above says much the same about keystone | |
| 13:18:57 | mordred | samueldmq: ^^ | |
| 13:32:35 | samueldmq | mordred: awesome, thanks for confirming | |
| 13:32:54 | samueldmq | that helps answering the question "why does sdk not support those API versions?" | |
| 13:32:55 | mordred | dtantsur: so - in a very slow answer to your question - yes, you should be worried about http methods ignoring error_message ... error_message is a parameter to _adapter._json_response - so that means we missed an update to a callsite | |
| 13:32:59 | mordred | samueldmq: ++ | |
| 13:33:13 | samueldmq | mordred: it would probably be useful to have that somewhere in our docs | |
| 13:33:19 | dtantsur | mordred: that's what I suspected | |
| 14:15:46 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Use network proxy in openstack.cloud https://review.openstack.org/604645 | |
| 14:15:47 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Start shifting cloud object-store methods to proxy https://review.openstack.org/608317 | |
| 14:15:47 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Remove all the deprecated stuff https://review.openstack.org/605508 | |
| 14:15:48 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Revert the Proxy metaclass https://review.openstack.org/609747 | |
| 14:15:48 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin https://review.openstack.org/608318 | |
| 14:15:49 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Rearrange shade image code https://review.openstack.org/609683 | |
| 14:16:03 | mordred | dtantsur: ok. I think 604645 is good now | |
| 14:20:04 | dtantsur | great :) | |
| 14:20:22 | dtantsur | mordred: re _normalize_* stuffs: what is its role? | |
| 14:20:36 | dtantsur | I thought as a bare minimum we should remove "links", etc? | |