| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-06-21 | |||
| 11:49:24 | mordred | tellesnobrega: dtroyer has been working on fixing the volumetype tests | |
| 11:49:39 | mordred | tellesnobrega: here: https://review.openstack.org/#/c/575448/ | |
| 11:49:56 | tellesnobrega | mordred, awesome, thanks. just wanted to be sure I didn't break the whole thing | |
| 11:50:08 | mordred | nope - not you :) | |
| 11:50:24 | tellesnobrega | cool | |
| 11:50:39 | tellesnobrega | not this time anyway, you never know | |
| 11:50:41 | tellesnobrega | :) | |
| 12:07:53 | mordred | hehe | |
| 12:24:06 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Adds Senlin support to openstacksdk https://review.openstack.org/576650 | |
| 12:26:16 | openstackgerrit | Jens Harbott (frickler) proposed openstack/python-openstackclient master: Fix volume type functional tests https://review.openstack.org/575448 | |
| 12:27:23 | frickler | dtroyer: ^^ one step further, but there is still seeing something fishy with the v3 volume type stuff. the c-api logs errors about "'all_tenants' filter key is not valid." but I cannot find where this comes from | |
| 12:28:05 | frickler | reading even | |
| 12:29:36 | mordred | frickler: I find it better to never think about or read anything I type | |
| 12:30:58 | frickler | mordred: words of wisdom indeed | |
| 12:31:50 | frickler | mnaser: I found some log in #os-cinder where you seemed to have a similar issue with volume types, did you find a solution for that? | |
| 12:41:15 | frickler | mnaser: dtroyer: I found a reference to the patch in python-cinderclient that breaks us and created https://bugs.launchpad.net/python-cinderclient/+bug/1778055 , when that is fixed we should be good again together with the patch above. | |
| 12:41:16 | openstack | Launchpad bug 1778055 in python-cinderclient "Change in search behaviour for v3 volume type breaks OSC" [Undecided,New] | |
| 12:41:37 | frickler | I think we should disable volume type v3 tests until then | |
| 12:57:55 | mnaser | frickler: Thank you | |
| 13:01:07 | rcarrillocruz | hey folks | |
| 13:01:56 | frickler | mnaser: I also just confirmed that reverting the patch in question would fix the issue for me locally, but I'll give cinder folks a bit to come up with a better solution | |
| 13:01:58 | rcarrillocruz | does https://docs.openstack.org/keystone/queens/user/application_credentials.html work since queens onwards? And is there a need to have some specific setting on keystone config to use that from end user perspective or providing Queens/ |
|
| 13:02:08 | rcarrillocruz | mnaser, mordred ^ | |
| 13:02:22 | rcarrillocruz | you deal with quite a bit of clouds :-) | |
| 13:03:05 | mnaser | frickler: yeah it quite most definetly is the cause. Let’s see what happens | |
| 13:03:27 | mnaser | rcarrillocruz: i think it’s just a Queens feature | |
| 13:03:51 | rcarrillocruz | mnaser: where's vexxhost version at? | |
| 13:04:05 | mnaser | Queens :) | |
| 13:04:11 | rcarrillocruz | i'm golden :-) | |
| 13:04:15 | rcarrillocruz | thanks | |
| 13:04:36 | mnaser | Let me know how it goes. I think cmurphy might be interested to see your experience too :) | |
| 13:05:39 | rcarrillocruz | ++ | |
| 13:07:42 | mordred | rcarrillocruz: yah - I hven't actually used them from shade/ansible yet - but it should just work | |
| 13:16:27 | cmurphy | rcarrillocruz: you need to have [auth]/methods = [...], application_credential in keystone.conf which is the default in queens, otherwise it should just work | |
| 13:17:14 | cmurphy | and yeah we haven't added the crud parts to shade yet but it shade should be able to use them via os-c-c etc | |
| 13:18:22 | rcarrillocruz | cool thx | |
| 13:20:28 | mordred | rcarrillocruz: auth_type: v3applicationcredential in clouds.yaml fwiw | |
| 13:30:11 | rcarrillocruz | hmm | |
| 13:30:13 | rcarrillocruz | wait a minute | |
| 13:30:51 | rcarrillocruz | mnaser: https://github.com/terraform-providers/terraform-provider-openstack/blob/master/openstack/import_openstack_vpnaas_ipsecpolicy_v2_test.go , does that mean vexxhost has vpnaas ? i see you are helping out that provider testing, but not sure if vpnaas comes from a devstack or you are already indeed giving that service | |
| 13:32:05 | mnaser | rcarrillocruz: it should be available and working, if it is not please let me know and i'll dig into it | |
| 13:32:13 | mnaser | there is a very small volume of users, people end up wanting to spin up their own vms | |
| 13:32:41 | rcarrillocruz | this is awesome | |
| 13:32:55 | rcarrillocruz | i'm part of ansible network (thx for the tenant btw) | |
| 13:32:58 | rcarrillocruz | working on https://github.com/ansible-network/cloud-vpn | |
| 13:33:05 | rcarrillocruz | which is a multicloud vpn role | |
| 13:33:19 | rcarrillocruz | if vpnaas is available there, perfect excuse to add support by using it | |
| 13:33:20 | rcarrillocruz | :-) | |
| 13:50:12 | dtroyer | mnaser, frickler: thank you! the v3 volume tests are just passthrough to v2 (which I really never liked) and this may be the first instance of us getting bitten hard by different behaviour... | |
| 13:53:56 | frickler | dtroyer: iiuc the tests are fine, its just that python-cinderclient broke things for their v3 manager | |
| 13:57:08 | mnaser | frickler: yep ,that was the issue | |
| 13:57:12 | mnaser | rcarrillocruz: sweet :) | |
| 14:01:12 | openstackgerrit | Lance Bragstad proposed openstack/python-openstackclient master: Implement support for registered limits https://review.openstack.org/574475 | |
| 14:01:13 | openstackgerrit | Lance Bragstad proposed openstack/python-openstackclient master: Implement support for project limits https://review.openstack.org/575211 | |
| 14:58:19 | slaweq | dtroyer: hi, can You find few minutes to check my last comment in https://review.openstack.org/#/c/567620/ ? | |
| 14:58:23 | slaweq | dtroyer: thx in advance | |
| 15:24:37 | cdent | elmiko, edleafe, dtantsur : I'm going to be on the phone but in attendance during the api-sig meeting, so if one of you can chair/newsletter/etc. At some point I will be on two calls... sigh | |
| 15:28:41 | dtantsur | cdent: I can chair, sure | |
| 15:31:21 | elmiko | cdent: ack | |
| 16:48:39 | elmiko | cdent edleafe dtantsur ready for review/editing https://etherpad.openstack.org/p/api-sig-newsletter | |
| 16:50:06 | cdent | elmiko: your last paragraph seems to suggest there are two new reviews, but they are the same one? | |
| 16:51:37 | elmiko | i'll clarify | |
| 16:51:52 | edleafe | elmiko: what is the storyboard naming issue? The -wg to -sig thing? That will be done as part of the gerrit project rename | |
| 16:52:29 | elmiko | edleafe: that was it, maybe not even worth mentioning? | |
| 16:52:40 | edleafe | I don't think so. | |
| 16:52:50 | elmiko | ack | |
| 16:53:31 | elmiko | thanks edleafe | |
| 16:54:25 | edleafe | cdent: "in addition" vs "an addition"? | |
| 16:55:30 | edleafe | elmiko: lgtm now | |
| 16:55:55 | elmiko | cool, sending | |
| 16:56:06 | cdent | ah yeah, | |
| 16:56:49 | elmiko | did i send too quickly? | |
| 16:57:22 | edleafe | elmiko: no, it's fine | |
| 16:58:07 | elmiko | k | |
| 17:57:06 | flwang1 | mordred: still around? | |
| 17:57:28 | mordred | flwang1: yup! | |
| 17:57:58 | mordred | flwang1: and yes, I mean implement the code in openstacksdk - the shade code is in openstack/cloud/openstackcloud.py in the openstacksdk repo | |
| 17:58:08 | mordred | so it's basically the same thing at the moment - there's just two copies of it | |
| 17:58:26 | flwang1 | i think openstackclient is using the correct magnum api now | |
| 17:58:34 | flwang1 | ok | |
| 17:58:36 | flwang1 | got it | |
| 17:59:01 | mordred | woot | |
| 17:59:42 | mordred | definitely let me know if you have any issues - but we also have a magnum functional test job, so we should be set up for you | |
| 18:00:00 | flwang1 | fantastic, thanks | |
| 19:02:03 | openstackgerrit | Ken Giusti proposed openstack/cliff master: Add test case for interactive help https://review.openstack.org/576900 | |
| 22:10:28 | flwang1 | mordred: seems shade only supports cluster template of magnum, no cluster CRUD? | |
| 22:11:45 | mordred | flwang1: yes - the magnum support was started by someone and then they got reassigned so it never progressed further | |
| 22:12:27 | flwang1 | mordred: then i'm wondering how should I name the function because I see senlin is trying to use the name like create_cluster.... | |
| 22:13:41 | flwang1 | what's the rule in shade world for the name convention issue? | |
| 22:15:13 | mordred | flwang1: it's an excellent question - so far we haven't had much conflict - but when we have I think we've tried to figure out some way to distinguish the resources | |
| 22:16:25 | mordred | flwang1: is there a decent generic word to describe what the magnum cluster is a cluster of? | |
| 22:17:20 | flwang1 | mordred: i think create_cluster could be better fitting for Senlin, but the problem is Magnum has already used the xxx_cluster_template, so it's a little bit tricky | |
| 22:17:52 | flwang1 | otherwise, I think personally, i don't mind using xxxx_coe_cluster, xxx_coe_cluster_template, just like we did for OpenStackClient | |
| 22:17:56 | mordred | flwang1: well - we can rename it and make an alias for backwards compat if there's a better word | |
| 22:17:58 | mordred | flwang1: ++ | |
| 22:19:10 | flwang1 | ok, then let's add the new xxx_coe_cluster_template and link it back to xxx_cluster_template, and deprecate the xxx_cluster_template in the future | |
| 22:19:15 | flwang1 | deal? | |
| 22:19:21 | mordred | sounds perfect to me | |
| 22:19:51 | flwang1 | mordred: fantastic, thanks, i will propose patch separately for template and cluster | |
| 22:19:59 | flwang1 | to make review easier | |