| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-13 | |||
| 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: Remove all the deprecated stuff https://review.openstack.org/605508 | |
| 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:48 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin https://review.openstack.org/608318 | |
| 14:15:48 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Revert the Proxy metaclass https://review.openstack.org/609747 | |
| 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 | |
| 15:07:29 | dtantsur | currently we're quite inconsistent, at least in the baremetal world | |
| 15:08:12 | mordred | yah. I agre - consistency is the most important | |
| 15:09:07 | mordred | dtantsur: to me I think it's more important that we get to a place where you get the same return object whether you use shade layer or proxy layer - because that way you can write nicer programs that sometimes use a higher-level helper method and sometimes lower-level methods | |
| 15:09:43 | dtantsur | okay, then hiding links probably does not make much sense.. | |
| 15:09:47 | mordred | yah | |
| 15:10:15 | dtantsur | okay, so I'll probably drop _normalize_machine and won't introduce _normalize_nic | |
| 15:23:39 | mordred | ++ | |
| 15:47:34 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Use proxy layer in shade networks https://review.openstack.org/610624 | |
| 15:47:57 | mordred | samueldmq: there's a half-written stab at using self.network.networks() for list_networks ... | |
| 15:50:06 | mordred | samueldmq: which I think may get us further than doing new normalize methods like https://review.openstack.org/#/c/602218 | |
| 15:50:46 | dtantsur | heh, openstackcloud.py is so big, it even makes vim slow :D | |
| 15:50:58 | mordred | dtantsur: hehe | |
| 15:51:26 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: Switch bare metal NIC actions in OpenStackCloud to baremetal Proxy calls https://review.openstack.org/610024 | |
| 16:06:53 | samueldmq | mordred: kk, I'll take a look at that today | |
| 16:07:11 | samueldmq | mordred: it'd be awesome to have that and the rest of the patches approved soon | |
| 16:07:19 | samueldmq | they're all ready for review, passing tests | |
| 16:08:42 | mordred | yah | |
| 16:09:39 | mordred | samueldmq: it's also possible that what we should do is start by landing your normalize patches (possibly making sure that they normalize things into a form that also looks like the fields in the Resource classes) | |
| 16:09:48 | samueldmq | except for a _metadata test that insists on failing intermitently | |
| 16:10:03 | samueldmq | mordred: have you seen some gates breaking with taht? | |
| 16:10:21 | mordred | and then a second set of patches to shift to using Resource- so that we can see the test updates along with the normalize (I think we're likely going to need to change some of the tests to be better) | |
| 16:10:30 | samueldmq | mordred: ++ | |