| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-03 | |||
| 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 | |
| 14:24:53 | smcginnis | brtknr: I'm not sure we are fully ready for Python 3.7 yet. | |
| 14:29:16 | brtknr | Well, it appears to work when I make this change: http://paste.openstack.org/show/731490/ | |
| 14:29:48 | brtknr | But I also saw this pending change on gerrit: https://review.openstack.org/#/c/597699/2 | |
| 14:30:16 | brtknr | Last updated 30th August.... | |
| 14:31:13 | brtknr | Looking at the number of changes relating to this issue, looks like its a touchy subject... | |
| 14:31:37 | brtknr | for e.g. https://review.openstack.org/#/c/584920/1 | |
| 14:32:08 | frickler | brtknr: our target for this cycle is to get all things working with 3.6, so 3.7 is still a bit down the road I think | |
| 14:32:19 | brtknr | And this: https://review.openstack.org/#/c/581886/1/osc_lib/utils/__init__.py | |
| 14:34:00 | brtknr | dtantsur: who are you? why do you speak in 3rd person | |
| 14:34:04 | brtknr | ? | |
| 14:35:32 | dtantsur | brtknr: https://www.livinginternet.com/r/ra_action.htm | |
| 14:38:33 | smcginnis | :) | |
| 15:02:35 | brtknr | my py37 tox test is passing when i change issubclass back to isinstance... http://paste.openstack.org/show/731499/ | |
| 15:03:00 | brtknr | according to this patch | |
| 15:03:02 | brtknr | http://paste.openstack.org/show/731490/ | |
| 15:03:47 | brtknr | on the other hand, its failing without the patch: http://paste.openstack.org/show/731500/ | |
| 15:04:57 | brtknr | It also fails for py27 without the patch! | |
| 15:05:12 | brtknr | ... wait no it doesnt | |
| 15:05:18 | brtknr | ... my bad | |
| 15:13:21 | openstackgerrit | Stephen Finucane proposed openstack/os-api-ref master: tests: Support Sphinx 1.8+ https://review.openstack.org/607984 | |
| 15:14:01 | stephenfin | dhellmann: Would appreciate your Python-fu on the above. I'm not sure why a mock decorator on the class isn't working | |
| 15:14:12 | stephenfin | dhellmann: Specifically https://review.openstack.org/607984 | |
| 15:29:47 | mordred | cdent: oh - yeah, I can't stand py.test | |
| 15:31:01 | mordred | cdent: but that's not why I'd suggest not using it in an openstack context - the main thing is that we have a bunch of infrastructure that's based around subunit streams | |
| 15:31:25 | mordred | cdent: so far attempts to make a subunit output plugin for py.test have all died on the vine | |
| 15:31:51 | cdent | yeah, that's my recollection from early gabbi too: can work however, as long as it can output subunit | |
| 15:31:56 | mordred | yah | |
| 15:32:21 | dtantsur | mordred: out of curiosity: why can't you stand py.test? | |
| 15:32:21 | mordred | I thinik it would be good for the world if someone would write a good subunit plugin for py.test | |
| 15:32:51 | mordred | dtantsur: I find the way the magical fixtures work impossible to read/follow | |
| 15:33:01 | mordred | in talking about it as a unittest library | |
| 15:33:45 | mordred | but also - the 'I'm a test runner and also a unittest library' annoys me since there is a unittest discovery protocol in core python - so nose and py.test mixing the two concerns is annoying | |
| 15:34:21 | dtantsur | agreed | |
| 15:34:35 | cdent | i think the original assertion with py.test, long before it became so magic, was that unittest (as mode and as a library) is entirely unpythonic, which I agree with | |
| 15:34:44 | mordred | when we write tests that follow the standard unittest discovery protocol - then people are free to use py.test or stestr or nosetests on the command line as they feel like | |
| 15:34:45 | cdent | when it moved on from holger it got a bit out of hand | |
| 15:42:00 | mordred | many things do | |