| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-07-24 | |||
| 08:04:37 | thanhnb | :( | |
| 08:05:27 | cmurphy | actually now i've tried it on a different system and it's giving me a completely different error, "Auth plugin requires parameters which were not given: auth_url" so i'm even more confused :) | |
| 08:06:21 | thanhnb | i has openstack in centos 7 | |
| 08:06:30 | thanhnb | and run code in ubuntu18 @@ | |
| 08:07:23 | thanhnb | i has same bug "not given: auth_url" when i dont declared "auth_url" | |
| 08:08:12 | thanhnb | my openstack is queen | |
| 08:09:15 | thanhnb | @@ | |
| 08:13:03 | thanhnb | i have tried it in different node, but it still error | |
| 08:15:45 | cmurphy | thanhnb: aha i reproduced your problem | |
| 08:15:55 | thanhnb | wow :D | |
| 08:15:59 | cmurphy | when I first tried it I had credentials set in OS_* environment variables | |
| 08:16:10 | cmurphy | if i unset OS_PASSWORD then the problem occurs | |
| 08:17:02 | cmurphy | based on that doc i think that's probably not what's intended, want to file a bug? | |
| 08:17:58 | thanhnb | so i need "OS_PASSWORD" in my environment? | |
| 08:18:22 | thanhnb | what is "want to file a bug" , i dont understand @@ | |
| 08:18:40 | thanhnb | i just newbie in openstack | |
| 08:20:09 | cmurphy | thanhnb: i mean to say, could you report this bug in the bug tracker? I believe you can do that here https://storyboard.openstack.org/#!/project/972 | |
| 08:20:56 | thanhnb | yes, i think i can do this. | |
| 08:20:59 | thanhnb | :) | |
| 08:21:02 | cmurphy | :) | |
| 08:21:19 | cmurphy | cc mordred ^ | |
| 12:15:39 | mordred | cmurphy: reading | |
| 12:16:30 | mordred | oh poo. thanhnb is gone | |
| 12:20:32 | mordred | cmurphy: fwiw, I think this is a doc bug - it is implying that the above is something that people should do | |
| 12:25:10 | mordred | the whole "Using an existing authenticated keystoneauth1.session.Session, such as might..." is really meant for inside of nova or something else where keystone_middleware has already provided a Session - I don't expect it to be a pattern people use in any other context | |
| 13:07:36 | cmurphy | mordred: but in theory shouldn't that work? | |
| 13:07:55 | mordred | yes - in theory it should work - so I'm sure there is a bug in there somewhere | |
| 13:08:29 | mordred | but the first bug is that doing it that way is the hardest possible way to use openstacksdk, so if someone is trying to get started and that's the way they're trying to get started, the docs are leading them astray | |
| 13:09:09 | mordred | (I'm especially curious as to why you having OS_PASSWORD set in the env had any impact at all due to the way session is saved and reused in that workflow) | |
| 13:09:11 | cmurphy | fair enough, it led me astray too | |
| 13:09:38 | mordred | like - that session has an Auth plugin already, so openstacksdk should not be doing _anything_ with auth information | |
| 13:09:53 | cmurphy | exactly | |
| 13:09:57 | cmurphy | that is what was surprising | |
| 13:10:00 | mordred | ++ | |
| 13:21:56 | openstackgerrit | Eric Fried proposed openstack/os-service-types master: Switch to stestr https://review.openstack.org/585349 | |
| 13:22:17 | openstackgerrit | Eric Fried proposed openstack/os-service-types master: Updated from OpenStack Service Type Authority https://review.openstack.org/585062 | |
| 13:44:04 | openstackgerrit | Eric Fried proposed openstack/os-service-types master: Switch to stestr https://review.openstack.org/585349 | |
| 14:19:04 | openstackgerrit | Eric Fried proposed openstack/os-service-types master: Switch to stestr https://review.openstack.org/585349 | |
| 15:09:50 | openstackgerrit | Artom Lifshitz proposed openstack/python-openstackclient master: Don't sent disk_over_commit if nova api > 2.24 https://review.openstack.org/582334 | |
| 15:17:59 | openstackgerrit | Monty Taylor proposed openstack/os-service-types master: Updated from OpenStack Service Type Authority https://review.openstack.org/585062 | |
| 15:44:47 | samueldmq | heya | |
| 15:45:15 | samueldmq | how many clouds have we validated shade (or the upper abstraction layer) against? | |
| 15:45:25 | samueldmq | mordred: ^ | |
| 15:45:30 | mordred | samueldmq: many :) | |
| 15:46:04 | samueldmq | mordred: nice, I'd like to do some formal validation and report results | |
| 15:46:06 | mordred | samueldmq: all of the openstack public clouds- and many of the private (I don't have a count) | |
| 15:46:16 | samueldmq | I was thinking about all those in the passport program to start | |
| 15:46:30 | samueldmq | oh that's awesome ... | |
| 15:46:54 | mordred | samueldmq: sweet. you may also want to talk to melvinhillsman - the openlab folks have been working on setting up jobs to run openstacksdk tests against actual public cloud accounts | |
| 15:47:00 | rcarrillocruz | yah, openlab, that | |
| 15:47:10 | samueldmq | rcarrillocruz: o/ | |
| 15:47:21 | rcarrillocruz | o/ | |
| 15:47:35 | samueldmq | mordred: awesome, I met him at last summit, will talk to him | |
| 15:48:00 | openstackgerrit | Monty Taylor proposed openstack/os-service-types master: Allow passing in service types with _ in them https://review.openstack.org/585410 | |
| 15:48:01 | openstackgerrit | Monty Taylor proposed openstack/os-service-types master: Add flag for returning unofficial types https://review.openstack.org/585411 | |
| 15:48:58 | mordred | samueldmq: woot. | |
| 15:49:22 | samueldmq | mordred: where is shade code in the new -sdk? | |
| 15:49:37 | mordred | samueldmq: although - for your case, it's also possible that doing the formal validation by hand would be fine - since that's different from making sure to run validation on every patch | |
| 15:49:44 | mordred | samueldmq: openstack/cloud | |
| 15:50:03 | samueldmq | mordred: ++ exactly... just want to validate the tool works | |
| 15:50:11 | samueldmq | also, I don't need/want to be exhaustive or too complex | |
| 15:50:22 | mordred | samueldmq: and it's all attached to the Connection object - so as a user if you do "conn - openstack.connect(cloud='vexxhost')" - you can use that conn object same as the OpenStackCloud object from shade | |
| 15:50:26 | mordred | samueldmq: ++ | |
| 15:50:41 | samueldmq | validating a core set of functionalities should be fine (whatever be a core set: vm managemnt?) | |
| 15:50:56 | mordred | samueldmq: https://review.openstack.org/#/c/582459/ is a patch you might want to look at | |
| 15:51:27 | mordred | samueldmq: it's a patch to allow running our ansible tests against a public cloud that is not devstack | |
| 15:51:39 | mordred | Shrews: ^^ speaking of - you might want to check out that patch too | |
| 15:51:50 | samueldmq | mordred: awesome | |
| 15:51:56 | samueldmq | do all the tests normally pass? | |
| 15:52:17 | samueldmq | I wouldn't be surprised otherwise... there may be some services that do not exist in some cases, for ex | |
| 15:52:33 | mordred | samueldmq: well - our ansible tests have a pretty small surface area | |
| 15:53:06 | mordred | I'd love to be able to run our functional tests against a cloud - and hopefully we'll also get that working at some point | |
| 15:53:20 | samueldmq | mordred: how do you see that? | |
| 15:53:21 | mordred | samueldmq: and I think it's ok for the test suite to skip some tests if they don't have a service | |
| 15:53:27 | samueldmq | reimplement with ansible | |
| 15:53:36 | samueldmq | or wrap the existing tests somehow to make it owrk | |
| 15:53:39 | mordred | nah - it's mostly just about reworking base fixtures | |
| 15:54:06 | mordred | in some clouds we may not have admin, for instance, so making a new project and testing keystone admin functions should all be skipped | |
| 15:54:08 | samueldmq | to allow oyu input the cloud to talk against | |
| 15:54:11 | mordred | but we could still test that booting a vm works | |
| 15:54:15 | samueldmq | when running tests right | |
| 15:55:22 | mordred | the tests already will skip if the service doesn't exist - then we have a devstack-specific test that responds to env vars and fails if an envvar asserts a service should exist but the shade tests don't find it | |
| 15:55:31 | mordred | that way we can make sure we don't accidentally fail open | |
| 15:55:36 | mordred | i the gate | |
| 15:55:48 | mordred | so we could probably expand on that somehow | |
| 15:56:10 | Shrews | mordred: lgtm | |
| 15:56:12 | mordred | to allow manual running against public clouds to be more flexible without sacrificing gate stuff | |
| 15:56:14 | mordred | Shrews: woot | |
| 15:56:18 | samueldmq | mordred: how are those vars set up then? | |
| 15:56:29 | samueldmq | I assume that cn be automatic by looking up the service catalog | |
| 15:56:34 | samueldmq | but would require some work | |
| 15:56:48 | mordred | well - "has_service('network')" uses the service catalog | |
| 15:56:54 | mordred | but the env var is defined in the test job | |
| 15:57:18 | mordred | so the test job (which sets up the services in the first place) also sets vars that say "I believe I set up magnum" | |
| 15:57:32 | mordred | then the shade test says "the test config expects magnum, do I see it in the catalog" | |
| 15:57:41 | samueldmq | ah makes sense | |
| 15:57:48 | samueldmq | but none of that apply to manual run | |
| 15:57:51 | mordred | exactly | |
| 15:58:01 | samueldmq | also, runnig against real public clouds wouldn't require any setup | |
| 15:58:08 | mordred | that's the theory :) | |