| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-27 | |||
| 15:11:17 | openstackgerrit | Monty Taylor proposed openstack/service-types-authority master: Add an attribute for aliases https://review.openstack.org/460539 | |
| 15:45:45 | briancurtin | Qiming: https://pypi.python.org/pypi/openstacksdk/0.9.16 released. doesn’t have a whole lot, just the porting changes plus two neutron changes | |
| 15:47:35 | openstackgerrit | Eric Fried proposed openstack/keystoneauth master: WIP: Introduce keystoneauth1.loading.adapter https://review.openstack.org/460337 | |
| 15:50:17 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add support for historical service type aliases https://review.openstack.org/460654 | |
| 15:50:57 | mordred | dtroyer: ^^ that should handle your feedback about volumev2 and friends | |
| 15:52:57 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add document describing consuming discovery https://review.openstack.org/459405 | |
| 15:52:57 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add support for historical service type aliases https://review.openstack.org/460654 | |
| 15:59:50 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guideline describing a cloud profile document https://review.openstack.org/459869 | |
| 15:59:50 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guidelines on Version Discovery https://review.openstack.org/459710 | |
| 15:59:51 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add a guideline about use of the service catalog https://review.openstack.org/460656 | |
| 16:20:54 | openstackgerrit | Chris Dent proposed openstack/api-wg master: Create a set of api interoperability guidelines https://review.openstack.org/421846 | |
| 16:51:57 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Port metric v1 to resource2 https://review.openstack.org/460673 | |
| 16:52:17 | openstackgerrit | Merged openstack/api-wg master: Define pagination guidelines https://review.openstack.org/446716 | |
| 16:52:22 | openstackgerrit | Merged openstack/api-wg master: Recommend the correct HTTP method for tags https://review.openstack.org/451536 | |
| 16:54:43 | openstack | Launchpad bug 1680446 in OpenStack SDK "Adding a User in a Project is not Possible" [Critical,Confirmed] - Assigned to Brian Curtin (brian.curtin) | |
| 16:54:43 | briancurtin | _alastor_: https://bugs.launchpad.net/python-openstacksdk/+bug/1680446 we don’t fully support what you’re looking for right now. yet | |
| 16:55:25 | _alastor_ | briancurtin: ok, looks like I'll probably just have to call out to the CLI for that functionality right now | |
| 16:58:47 | _alastor_ | briancurtin: also, based on what Dave is saying in that bug, I could get a Project object and use those helper methods to accomplish what I need | |
| 17:00:17 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix Nova-net netowrk commands https://review.openstack.org/460679 | |
| 17:00:29 | elmiko | cdent: you doin the newsletter now? | |
| 17:00:38 | cdent | yeah | |
| 17:00:43 | elmiko | gonna leave for lunch soon, but i'll wait around | |
| 17:00:45 | elmiko | cool | |
| 17:00:50 | cdent | elmiko: don't worry | |
| 17:00:58 | cdent | I'll read it closely | |
| 17:01:04 | elmiko | haha | |
| 17:01:06 | cdent | if you're not about, it'll be fine | |
| 17:01:18 | elmiko | nah, it's all good. it's raining here anyways, so i am putting off a soggy walk | |
| 17:04:59 | cdent | mordred: what are the forces that would cause delay from when a new api-wg is +W (and announced as merged above) and when it shows up on specs.openstack.org? | |
| 17:05:30 | cdent | or rather: is that delay predictable? | |
| 17:10:30 | cdent | (it's caught up now) | |
| 17:18:06 | elmiko | cdent: please attend, maybe we need "GET YO ASS THERE!" | |
| 17:18:22 | elmiko | too strong? | |
| 17:19:01 | elmiko | haha | |
| 17:19:11 | briancurtin | _alastor_: yeah, i think so. it’s not the ideal interface, but it might do what you need for now. I’m in the middle of getting some other changes out, but we should be able to add what’s needed in that bug and what you’re doing fairly soon | |
| 17:19:50 | cdent | elmiko: any thing to add? | |
| 17:20:39 | elmiko | cdent: lgtm | |
| 17:20:56 | elmiko | second para is a little passive-aggressive, but i think it's worth it | |
| 17:21:11 | cdent | yeah, I waffled on that and then decided "why not?" | |
| 17:21:26 | elmiko | i'm with you, we need to shake the tree if we are going to get some fruit in this case | |
| 17:22:18 | cdent | shipped | |
| 17:22:26 | mordred | cdent: the delay is mostly just that publication jobs run just like any other one, so it's gotta get queued up, wait for a node to become available, then get built and published | |
| 17:22:45 | cdent | elmiko: while you lunch, I will dine | |
| 17:22:51 | elmiko | cdent: enjoy =) | |
| 17:23:21 | cdent | mordred: ah, I hadn't really considered that the publish jobs would get a new node. makes sense now | |
| 17:48:13 | gouthamr | edleafe: Re: '<edleafe> Heat will have to find a new liaison, <edleafe> Manilla too' | |
| 17:49:01 | gouthamr | edleafe: manila had two liaisons, now it's one. however, more the merrier, i can ask for more people to help out | |
| 18:25:55 | edleafe | gouthamr: Ah, I misunderstood the email. Thanks for the clarification! | |
| 18:26:33 | edleafe | gouthamr: And we always welcome more participation | |
| 18:27:20 | gouthamr | edleafe: yep. i'll bring this up in the manila meeting soon :) | |
| 18:59:59 | dtroyer | Shall we do an OSC meeting? #openstack-meetin now-ish | |
| 19:18:47 | mordred | dtroyer: so - on the skip validating front, I've got this: https://review.openstack.org/#/c/438196/ - which TOTALLY skips that stuff until it's requested | |
| 19:19:05 | mordred | dtroyer: last we chatted about it you liked the idea but thought it was too soon / too much stuff still to unwind | |
| 19:19:24 | mordred | dtroyer: do you think its time to start tugging at that thread again? or still hold off for a bit? | |
| 19:20:41 | dtroyer | I was hoping the stuff jamielennox started that we talked about in ATL was going to handle that and I haven't gotten back to it yet | |
| 19:22:23 | dtroyer | so I forgot about that, and given what I've just unwound in OSC in prep for 1.27.0 I may be ready to go there now | |
| 19:22:29 | mordred | oh cool | |
| 19:22:42 | mordred | I'll get those two patches cleaned up and resubmitted for you | |
| 19:22:48 | mordred | and we can see how far off they are | |
| 19:23:12 | dtroyer | cool. I want to get the next OSC release out early next week, will dive in deeper after that | |
| 19:23:54 | mordred | something just broke shade's legacy functional test jobs | |
| 19:24:01 | mordred | which is the next thing _I_ get to look in to | |
| 20:24:50 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Port unversioned Version resources to resource2 https://review.openstack.org/460735 | |
| 20:36:06 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix Nova-net netowrk commands https://review.openstack.org/460679 | |
| 20:55:00 | efried | o/ | |
| 20:55:39 | efried | mordred Gonna be multitasking the nova mtg in 5, FYI. | |
| 20:57:16 | mordred | efried: me too - I'm still in this glorious phone call | |
| 20:57:59 | efried | mordred Cool, I'll just dump my questions and we can discuss as thread manager allows. | |
| 20:58:04 | mordred | sweet | |
| 20:59:47 | efried | So I noodled around with os-client-config a little bit. I found that I could get all the known ClientConfig instances - so first question is: how do I figure out which one to use? Or to know which one to get_one_cloud() for? | |
| 20:59:59 | efried | (or is that the wrong starting point entirely?) | |
| 21:00:32 | efried | Second, I found I couldn't do anything service_catalog-y with a CloudConfig unless I also supplied an auth somehow. I can set up the auth (by loading from conf options), but it's not clear me where/how I'm supposed to hand it off to the CloudConfig. | |
| 21:12:59 | mordred | efried: gotcha. good questions - SO - part of the issue is that the interfaces you're talking about in occ are oriented towards end-users | |
| 21:13:14 | mordred | efried: I put this together: https://review.openstack.org/#/c/439120/ | |
| 21:13:27 | mordred | efried: which needs to be finished | |
| 21:14:07 | mordred | efried: but the idea there woudl be to give you some nice factory functions that you could use to pass in your CONF object and the other context you have at the calling points in nova | |
| 21:14:31 | mordred | and have it return you either a ksa.adapter or a glanceclient.Client or a neutronclient.Client or whatever is appropriate | |
| 21:23:34 | efried | dtroyer If interested, here's where it's coming from: https://review.openstack.org/#/c/458257/ | |
| 21:25:11 | dtroyer | efried: thanks. my concerns are much more about policy and expectations than code itself, learned from experience. there's a reason I don't want most oslo bits in clients, they make server-side assumptions | |
| 21:26:33 | mordred | dtroyer: oh yah - I definitely agree about oslo and clients | |
| 21:27:21 | efried | dtroyer Mainly the issue that prompted this discussion was that we want to be able to divine an appropriate list of service_type values to try successively to discover the endpoint for a given conf group, if they don't set a service_type in their conf. | |
| 21:27:27 | mordred | dtroyer: in this case my suggestion was coming basically from seeing the amount of boilerplate (that's getting it wrong in several places) inside of nova when they're creating their clients to talk to the other services | |
| 21:27:43 | efried | Exactly, the point of this blueprint. | |
| 21:28:37 | mordred | dtroyer: the _basic_ thought was to make few functions that skip any processing of envvars or clouds.yaml files and only work via python-level parameters | |
| 21:28:55 | dtroyer | sure, and maybe some of that needs to be extracted. my worry is the constant tension between client and service versions and dependencies and expectations. I once thought the SDK should be so damn good that all of the services should use it too. bad idea. really bad idea in the real world | |
| 21:29:59 | mordred | dtroyer: yup. totally agree with the concern | |
| 21:30:00 | dtroyer | mordred: that requires a discipline we have yet to be able to maintain within a lib. | |
| 21:30:10 | efried | Baby steps, we can start by putting the boilerplate in one place (and hopefully getting it right); and then later offload more of that functionality to o-c-c (and/or service-types-authority) as appropriate. | |
| 21:30:16 | dtroyer | I'm onboard with the idea, just don't think o-c-c is the place fro shared client/service code | |
| 21:30:31 | mordred | to be fair - I think with the ksa patch efried wrote, we might be able to just deal with it all with some repeated patterns | |
| 21:30:41 | mordred | efried: ++ | |
| 21:30:55 | mordred | yah. I think the register_adapter_options in ksa is key | |
| 21:31:11 | dtroyer | ksa is a good example of us actually pulling this off. it'll take that level of discipline for dependencies and interfaces | |
| 21:31:17 | mordred | and then using session.get_endpoint | |
| 21:31:37 | efried | mordred With the exception of the "guess service_types for your group if not specified" thing, I have everything I need with the ksa patch. | |
| 21:31:45 | efried | That part is still the hole. | |
| 21:31:54 | mordred | because there's a few of the logic things nova needs that are in occ now but I think we may be close to being able to say that ksa should understand | |
| 21:32:11 | efried | I guess, back to baby steps, I can make service_type required for now...? | |
| 21:32:33 | efried | I don't think that'll make jaypipes happy, tho | |
| 21:32:34 | mordred | oh - yes - service_type is/should be required | |