Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-10-09
20:23:22 openstackgerrit Merged openstack/keystoneauth master: Allow initializing session with connection retries https://review.opendev.org/676648
#openstack-sdks - 2019-10-10
06:39:15 openstackgerrit pengyuesheng proposed openstack/os-service-types master: Blacklist sphinx 2.1.0 (autodoc bug) https://review.opendev.org/687795
07:04:11 openstackgerrit pengyuesheng proposed openstack/shade master: Blacklist sphinx 2.1.0 (autodoc bug) https://review.opendev.org/687800
16:03:56 elmiko API SIG office hour started 3 minutes ago XD
16:11:43 cdent BUSINESS!
16:11:47 elmiko LOL
16:11:57 elmiko long time no talk, how's life? =)
16:13:00 cdent It's time to go to Healey's Cyder Farm and get a pumpkin
16:13:10 elmiko ooh, nice!
16:15:21 cdent I did a thing recently that might be of api-sig interest, let me see if I can locate it
16:16:20 elmiko lol
16:18:16 cdent can't find it
16:18:19 cdent i hate etherpads
16:18:30 cdent unless you bookmark them all, they are _gone_
16:18:58 elmiko yeah, i've always wondered about some sort of etherpad indexing service, but i don't know if that goes against the spirit of etherpad
16:19:07 cdent there we go, yellow at the bottom: https://etherpad.openstack.org/p/PVG-u-series-goals
16:19:11 elmiko \o/
16:20:04 elmiko cdent: if i read your intentions, are you suggesting we should have a "frameworks" guidance doc or something?
16:20:19 cdent I'm not sure if I have an intention
16:20:28 cdent It's more that there was a series of events:
16:20:29 elmiko ack, misread on my part then
16:20:48 cdent discussion in nova about how the api paste file is a pain
16:21:04 cdent led to me saying "hey, I maintain pastedeploy, except I don't, we should stop using it"
16:21:20 cdent then I saw http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010037.html which mentioned that etherpad
16:21:33 cdent so I hailed mary and added an old tune we've heard before
16:21:56 cdent it kind of goes (to a nice blues beat) "let's stop using old stuff"
16:22:08 elmiko lol, yeah
16:22:59 elmiko i was under the impression that refactoring nova away from wsme and paste was considered a task too insurmountable for mere mortals. does it seem more realistic these days?
16:23:58 cdent i went down to austin / for to make me some cloud / yeah I went down to austin / and that cloud was not bad ...
16:24:08 cdent hmmm I am not a blues musician
16:24:17 cdent nova doesn't use wsme, thank fully
16:24:29 elmiko ahh, gotcha
16:24:34 elmiko i'm so out of touch lol
16:24:40 cdent but it does use pastedeploy
16:24:49 elmiko got it
16:24:52 cdent it's just that paste* and wsme are in a class of "old stuff"
16:25:42 elmiko yeah
16:25:45 cdent but yes, to bring it back round to the hereness of the api-sig
16:26:08 cdent it might make sense to have a "for new projects and services use maintained tools, so don't use x, y, z"
16:26:31 elmiko i like the way that is worded
16:27:00 elmiko maybe like a general tech suggestion guideline
16:27:43 elmiko i really don't want to get the api-sig into the business of naming and shaming, but i do like promoting good decision making based on sound principles
16:29:17 cdent I think by saying "use maintained stuff and not these known dead things" avoids naming a champion and is factual about the dead things
16:31:49 elmiko yes!
16:31:51 elmiko totally agree
16:32:20 cdent most successful BUSINESS meeting ever
16:32:25 elmiko i've been trying to work through the existing open pull requests we have, it's slow, but i think i could add this doc to the list.
16:33:25 elmiko thanks for the suggestion cdent, i've added it to my notes
16:33:34 cdent \o/
17:02:17 elmiko catch y'all later o/
20:01:19 enriquetaso dtroyer, what do you think of this backport to stable/queens https://review.opendev.org/#/c/679120/1 ? Is it acceptable ?
#openstack-sdks - 2019-10-12
06:41:31 openstackgerrit pengyuesheng proposed openstack/osc-lib master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688236
06:43:42 openstackgerrit pengyuesheng proposed openstack/os-client-config master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688237
07:19:07 openstackgerrit pengyuesheng proposed openstack/os-service-types master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688250
#openstack-sdks - 2019-10-14
08:32:43 openstackgerrit Bram Verschueren proposed openstack/openstacksdk master: Add support for additional volume backup options https://review.opendev.org/688353
10:09:25 openstackgerrit Merged openstack/openstacksdk master: Update the constraints url https://review.opendev.org/683862
12:06:30 openstackgerrit Bence Romsics proposed openstack/openstacksdk master: Add router add/remove route operations https://review.opendev.org/674324
12:06:49 openstackgerrit Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304
14:17:31 openstackgerrit Merged openstack/openstacksdk master: fix "How To Contribute" url https://review.opendev.org/682803
21:10:09 openstackgerrit Merged openstack/os-client-config master: Stop testing python2.7 https://review.opendev.org/686589
#openstack-sdks - 2019-10-15
00:15:04 openstackgerrit Brin Zhang proposed openstack/python-openstackclient master: WIP: Add server migrate list CLI https://review.opendev.org/675304
07:49:42 openstackgerrit Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304
09:03:54 openstackgerrit Brin Zhang proposed openstack/python-openstackclient master: WIP: Add server migrate list CLI https://review.opendev.org/675304
12:51:53 openstackgerrit Bram Verschueren proposed openstack/openstacksdk master: Add support for additional volume backup options https://review.opendev.org/688353
13:06:04 openstackgerrit Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704
17:57:18 openstackgerrit Jihad Dwidari proposed openstack/openstacksdk master: Use 'name' param if not UUID like https://review.opendev.org/688773
19:04:31 openstackgerrit Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704
#openstack-sdks - 2019-10-16
02:21:54 openstackgerrit Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.79: Add delete_on_termination to volume-attach API https://review.opendev.org/673725
14:31:43 openstackgerrit Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704
15:34:16 openstackgerrit Dan Smith proposed openstack/python-openstackclient master: WIP: Add aggregate cache images support https://review.opendev.org/688960
15:35:08 openstackgerrit Dan Smith proposed openstack/python-openstackclient master: WIP: Add aggregate cache images support https://review.opendev.org/688960
18:35:23 openstackgerrit Jihad Dwidari proposed openstack/openstacksdk master: Fixes get_user when identity responses are paged https://review.opendev.org/688704
20:11:06 openstackgerrit Andreas Jaeger proposed openstack/os-api-ref master: Use Ussuri jobs https://review.opendev.org/689032
21:01:51 rm_work in the SDK, there's two interfaces for clustering it seems, and for example the function `detach_policy_from_cluster` exists on both but has very different signatures
21:03:04 rm_work It seems like doing `sdk_cloud_obj.cluster.detach_policy_from_cluster(..)` uses `openstack.clustering.v1._proxy`, but I want to use `openstack.cloud._clustering`
21:03:34 rm_work any thoughts? mordred maybe?
21:14:44 rm_work ah! teammate found it. just directly do `sdk_cloud_obj.detach_policy_from_cluster` without the extra cluster step
21:16:37 mordred rm_work: yes - that's right. the cloud layer is what used to be shade - and that's totally the right way to use it
21:16:49 rm_work kk
21:17:03 rm_work so in general, avoid using the `.service.*` stuff
21:39:17 mordred rm_work: both are honestly fine to use 0 the service.* is a bit lower-level. the eventual goal is to have the cloud.* methods using the cloud.service.* methods under the covers
21:39:53 rm_work yeah k
21:40:31 rm_work just saw in the response to my ML thread about ospurge that the SDK folks wanted to include similar functionality *builtin*?
21:40:38 rm_work have you looked much at that?
22:29:28 mordred rm_work: yeah - it's actually a todo list item on my side that I was supposed to get started on this cycle but haven't managed to get to yet
22:29:47 rm_work cool
22:29:52 rm_work i'm interested
22:30:02 rm_work been working on ospurge
22:30:16 mordred sweet!
22:31:22 rm_work though i wish this was further along... we're going to end up in a situation where we deploy a cleanup solution with ospurge internally and then the official solution happens and we have to ... ... spend like three years maintaining a legacy thing and spinning up a project to replace it
22:31:22 rm_work lol
22:31:26 mordred I think the idea is that we'd put a call on the Connection object - maybe "purge_project" ? - and then we can have it call lower-level purge_project methods per-service or something like that
22:31:37 mordred rm_work: hah
22:31:49 rm_work i mean, ospurge actually does a pretty good job
22:31:58 mordred rm_work: well - maybe the answer there is to get the sdk purge support in - then make an ospurge release that just uses the purge call in sdk
22:32:02 rm_work could possibly look at lifting/merging some of that stuff in
22:32:05 mordred yeah
22:33:12 mordred I think one of the reasons people wanted it in sdk was so that we could re-consume it from non cli things more easily - so like expose it in heat and horizon and python-openstackclient and maybe adjutant?
22:33:25 rm_work yeah
22:33:31 mordred but I think lifting the ospurge logic in as a starting point would be *great*

Earlier   Later