| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-12 | |||
| 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? | |
| 14:53:56 | mordred | dtantsur: well - long term I think _normalize_* should go away and the data model contract should just be expressed in the Resource objects ... | |
| 14:54:22 | mordred | but that's a little handwavey | |
| 14:54:41 | dtantsur | the Resource objects do have a bit technical things like "links". do we want to keep them in the output? | |
| 15:05:13 | mordred | dtantsur: it's a good question. I'm less opposed to them than I was in years past because we have the underlying structure to do something with them now (it use to be you got a link in a novaclient object, but didn't have any configured rest client that could actually make a request from that link) | |
| 15:05:47 | mordred | so maybe they're ok to keep around now? or maybe they're a terrible idea ... | |
| 15:07:17 | dtantsur | I'm fine with either way, but we need it consistent | |