| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-03 | |||
| 13:51:53 | rosmaita | cdent: but that's probably too much detail. i guess the key thing is that a json-patch replace operation should actually replace stuff or fail (and not do weird side-effect stuff like we're proposing) | |
| 13:52:03 | cdent | you say in one of your initial comments " because the "validation_data" object does not exist in the image/location schema; it's sort of an instruction, really, that produces a side effect (the population of other properties on that image)". Can you just populate those properties? | |
| 13:52:35 | cdent | yes: if you're using json-patch replace, it should do json-patch replace, not some special glance-only magic | |
| 13:52:54 | rosmaita | cdent: yes, that's the alternative (but those properties are currently read-only in the schema, which is a sticking point) | |
| 13:53:37 | rosmaita | the issue is that we only want these properties to be settable under one specific circumstance, and never at any other time | |
| 13:53:40 | cdent | making them writable during certain states is probably OK | |
| 13:53:46 | cdent | jinxish | |
| 13:58:37 | cdent | rosmaita: Have I helped or just made it worse? | |
| 13:58:48 | rosmaita | cdent: thinking! | |
| 13:59:27 | rosmaita | cdent: last question ... if we make these writable under one tiny circumstance, then we have to remove readOnly: true from the schema for them, right? | |
| 14:01:21 | cdent | I think that depends on how you are using and publishing the schema. In my mind schema are a validation tool used indepdently for each method:resource pair, not a contract in an of themselves | |
| 14:03:09 | rosmaita | cdent: thanks, that is helpful and will give us something to think about | |
| 14:03:28 | cdent | you're welcome | |
| 16:37:04 | Luzi | mordred are you there? | |
| 16:37:23 | mordred | Luzi: *sortof* - I'm at a conference so I'm in and out | |
| 16:38:15 | Luzi | okay, short question: it is planned to use openstacksdk in more projects right? | |
| 16:38:23 | Luzi | like nova and cinder maybe? | |
| 16:39:38 | smcginnis | Nothing active that I've seen, but not out of the question. | |
| 16:42:27 | mordred | Luzi: yes - it's already in use in heat, senlin and masakari | |
| 16:42:48 | mordred | Luzi: once the 1.0 is cut, I'll start poking at making patches for folks to make that possible | |
| 16:43:15 | mordred | Luzi: I don't know that the various services have agreed that they want such a migration yet - but from my/sdk point of view, once 1.0 is out it's a great idea | |
| 16:43:43 | smcginnis | mordred: Forum topic? | |
| 16:44:08 | Luzi | mordred, thank you for now :) | |
| 16:44:20 | smcginnis | Too late now to be proposed, but we may be able to find a time for it if there is interest/need. | |
| 16:50:50 | mordred | smcginnis: yah. I was supposed to talk to nova about it in denver - but I missed the irc ping | |
| 18:45:45 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Split advanced networking services into a job https://review.openstack.org/607199 | |
| 19:35:34 | kmalloc | mordred: how far is SDK away from being ... usable say, in lieu of keystoneclient? | |
| 19:36:00 | kmalloc | mordred: i kindof want to leap early towards dropping ksc to the curb (new stuff only in SDK) | |
| 19:37:50 | mordred | kmalloc: we're very close to a 1.0 | |
| 19:37:58 | mordred | kmalloc: as soon asI can get the tests to stop OOMing | |
| 19:38:14 | kmalloc | mordred: re-stating what i said in -keystone | |
| 19:38:23 | kmalloc | mordred: because i want to jump early like we did for OSC as the cli | |
| 19:39:21 | kmalloc | mordred: i would love to draw the line in the sand this release and say "all new stuff goes in SDK, ksc is deprecated and will see no new changes except for compat/security if an API is materially changed [see security reasons]" | |
| 19:39:33 | kmalloc | mordred: specifically... for new things like oslo.limit | |
| 19:39:39 | kmalloc | mordred: so.. yay! | |
| 19:39:48 | kmalloc | mordred: and boo OOMing | |
| 19:40:17 | mordred | kmalloc: yes - I tihnk we're in a good place for that | |
| 19:40:25 | mordred | kmalloc: I don't know that we're at feature parity for the existing thing | |
| 19:41:54 | kmalloc | cool. I'll make my -1 a little less soft on forklifting in ksc into oslo.limit | |
| 19:41:58 | kmalloc | and say "lets use SDK" | |
| 19:42:07 | kmalloc | (referencing this convo) | |
| 19:42:45 | mordred | ++ | |
| 19:44:12 | kmalloc | https://review.openstack.org/#/c/596520/13 if you want to weigh in | |
| 19:44:32 | kmalloc | commented on it saying it's better to add support to SDK if needed than lean on ksc at this point. | |
| 19:44:45 | kmalloc | it's a super small set of API calls. | |
| 19:44:47 | kmalloc | we use there. | |
| 19:44:48 | mordred | kmalloc: I _certainly_ think it's valuable to start new dev that way. adding comment now | |
| 19:44:53 | kmalloc | :) | |
| 19:45:00 | mordred | kmalloc: well, and you can just use the rest layer worst case | |
| 19:45:13 | kmalloc | yeah, i said in my initial comment, use KSA not KSC. | |
| 19:45:23 | kmalloc | but figured I should talk here before firming up the -1 | |
| 19:45:34 | kmalloc | now i'm saying "SDK" | |
| 19:45:48 | kmalloc | i will also push hard that all new stuff will be in SDK vs in KSC. | |
| 19:46:10 | kmalloc | it does mean we'll need to look at how hard it will be to re-write our ksc-plugin for OSC under SDK. | |
| 19:46:14 | kmalloc | should be... doable | |
| 19:46:41 | kmalloc | if we can make our plugin SDK, then i know everything else could lean on SDK and be 90% parity | |
| 19:46:51 | mordred | yes! | |
| 19:47:05 | kmalloc | and 90% is good enough imo to deprecate (freeze) ksc. | |
| 19:48:56 | kmalloc | and that saves us the headache of fixing ksc's weird session stuff that is there for compat | |
| 19:50:37 | kmalloc | mordred: in the interest in sharing eyebleeding patches... because... well we can | |
| 19:50:48 | kmalloc | mordred: https://review.openstack.org/#/c/603461/ ::will make your eyes bleed:: | |
| 19:51:04 | kmalloc | mordred: but that is the worst forklift of keystone -> flask | |
| 21:05:57 | dtroyer | kmalloc: it's very easy to change commands to use the SDK, have a look at the network commands for how to use it directly, specifically security groups which handle both neutron and nova-net show how to hop between two at the same time | |
| 21:06:20 | kmalloc | Yep. Was looking at it just now | |
| 21:06:43 | kmalloc | About to embark on a "strip ksc from osc" crusade :) | |
| 21:06:46 | dtroyer | there are also some uses of sdk-network in the compute server commands IIRC | |
| 21:07:08 | kmalloc | If osc is on SDK for keystone, I can make the case ksc can die a slow death of bit rot. | |
| 21:07:27 | kmalloc | And all new things go sdk (carrot) for keystone. | |
| 21:07:46 | kmalloc | Similar to how ksc command line did a while back. | |
| 21:08:10 | dtroyer | second verse same as the first… | |
| 21:09:11 | kmalloc | Exactly | |
| 22:04:36 | kmalloc | woo, just got a new mechanical keyboard, and loving it | |
| 22:04:46 | kmalloc | yay cherry silver switches | |
| 22:04:57 | kmalloc | (and my other one for my workstation is cherry clears) | |
| #openstack-sdks - 2018-10-04 | |||
| 10:00:19 | dtantsur | mordred: OOM killer, w000t | |
| 10:00:40 | dtantsur | also my question re raising the minimum version was not exactly about raising a version of an existing service | |
| 10:01:11 | dtantsur | I'm writing a smart proxy for bare metal API, and I wonder if it's possible to not implement all 46-something microversions in it >_< | |
| 11:21:58 | cdent | stephenfin: what's the issue with pytest? | |
| 12:49:22 | stephenfin | cdent: IIRC, nose and pytest share the same problem: they're a-ok as test runners but its their use as a test library that raises objections | |
| 12:49:44 | cdent | that's a shame | |
| 12:49:49 | cdent | pytest is so much _better_ | |
| 12:50:11 | stephenfin | cdent: I'd suggest discussing that with mordred. He cares a *lot* about this stuff :) | |
| 12:51:23 | cdent | yeah, I'm not meaning to badger you, just wondered if you had some insight | |
| 12:51:45 | cdent | I ran up against similar resistance when creating gabbi. I didn't want it to be unitest-based | |
| 12:52:05 | cdent | but lifeless and a few others were super clear that I'd never get anywhere in openstack if it wasn't | |
| 12:56:08 | stephenfin | Yeah, mordred has explain his arguments for using it pretty well a couple of times but, alas, I never recorded them and can't find them now (maybe he should write a blog?) | |
| 12:56:55 | stephenfin | Fwiw though, while I enjoy the clever assertion handling, I'm really not a fan of the fixtures/markers. They're confusing and utterly unlike anything else I've seen in Python | |
| 13:04:38 | cdent | stephenfin: I agree that pytest lost its way | |
| 13:05:05 | cdent | I got into it in 2008ish, and back then it was very very very simple and I _loved_ it | |
| 13:05:19 | cdent | now, there's too many magics | |
| 13:05:34 | stephenfin | magic, yeah, that's the word | |
| 13:09:35 | stephenfin | It took me days to grok what on earth the Sphinx tests were doing and, even now, I'm carrying code for my own tests that I don't full understand. I blame pytest for a good chunk of that | |
| 13:09:44 | stephenfin | *fully | |
| 13:18:11 | cdent | when I added pytest support to dynamic test generation in gabbi, the very simple yield-based strategy that I had used back in 2009ish had been deprecated in favor of something insanely inscrutable | |
| 14:05:29 | cdent | you can still do non-magic in pytest, so it still has going for it | |
| 14:06:27 | brtknr | I'm using python-openstackclient with python 3.7 and im getting this: | |
| 14:06:29 | brtknr | (OS) ➜ osc-lib git:(master) openstack server list | |
| 14:06:31 | brtknr | issubclass() arg 1 must be a class | |
| 14:06:47 | brtknr | i can still using nova list | |
| 14:07:05 | brtknr | i also didnt have the issue with python 3.6 | |