| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-19 | |||
| 21:07:15 | sean-k-mooney | all of the flavor quota atibute came form the vmware driver originally | |
| 21:09:30 | larsks | Okay. So effectively the best practice is not to use instance resource limits for anything, and rely on the per-service limits (e.g., cinder, neutron) where available. Is that accurate? | |
| 21:10:02 | sean-k-mooney | if you want to have interop between different public cloud then you could not rely on that feature existing | |
| 21:10:39 | sean-k-mooney | as an operator you can set them but it may cause issues for your users if you also expose the service qos apis | |
| 21:10:44 | cdent | efried: https://bugs.launchpad.net/nova/+bug/1804062 the thing that I thought would fix it does not | |
| 21:10:45 | openstack | Launchpad bug 1804062 in OpenStack Compute (nova) "test_hacking fails for python 3.6.7 and newer" [Undecided,New] | |
| 21:10:47 | cdent | so still thinking | |
| 21:10:59 | larsks | sean-k-mooney: fair enough. Are there any plans to deprecate the feature in the near future? | |
| 21:11:18 | cdent | mriedem: to distract you, that bug ^ is real fun | |
| 21:11:36 | sean-k-mooney | larsks: again it kind of a if its not broken dont fix it or delete it situation | |
| 21:11:55 | sean-k-mooney | larsks: i dont think so but it has been mentioned in the past | |
| 21:12:36 | sean-k-mooney | larsks: a better way to look at it is it unlikely that we would add more quota: extraspec in the future | |
| 21:13:05 | larsks | Okay, that makes sense. Thanks for spending some time on this! | |
| 21:14:29 | cfriesen | is it just me or is it not intuitive that the way to get a vnc session to a server using the "openstack" command is "openstack console url show" rather than an "openstack server console show" or similar? | |
| 21:15:00 | sean-k-mooney | cfriesen: i did fine it weird too | |
| 21:15:19 | sean-k-mooney | its there to differenceate between the url or the log | |
| 21:15:45 | sean-k-mooney | but i would have gon with opesntack server console show and openstack server log show | |
| 21:16:48 | sean-k-mooney | cfriesen: sorry tehy are console log show and console url show | |
| 21:17:19 | sean-k-mooney | but yes openstack server console show and openstack server log show would have made more sense to me | |
| 21:19:21 | mriedem | cfriesen: likely a question for dtroyer in #openstack-sdks | |
| 21:20:27 | mriedem | cdent: so we're intermittently hitting that in py36 jobs? | |
| 21:20:34 | cdent | yes | |
| 21:21:02 | cdent | seems to depend on whether the node has a recently updated python. 3.6.7 was released to ubuntu not long ago | |
| 21:21:13 | sean-k-mooney | cdent: is that happening in nova or in the hacking repo? | |
| 21:21:18 | cdent | nova | |
| 21:21:44 | cdent | it's just the one test | |
| 21:22:02 | cdent | the root is that having a newline token being added on the end is causing pep8 to think it needs to do a "logical check" | |
| 21:22:11 | sean-k-mooney | can you past the test name again ill try and run it on python 3.6 on centos | |
| 21:22:18 | cdent | which means it bypasses the physical checks that happen otherwise | |
| 21:22:29 | cdent | sean-k-mooney: nova.tests.unit.test_hacking.HackingTestCase.test_check_doubled_words | |
| 21:22:40 | cdent | it ought to pass fine in <3.6.7 | |
| 21:22:46 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22testtools.matchers._impl.MismatchError%3A%20%5B(1%2C%200%2C%20'N343')%5D%20!%3D%20%5B%5D%5C%22%20AND%20tags%3A%5C%22console%5C%22%20AND%20build_name%3A%5C%22openstack-tox-py36%5C%22&from=7d | |
| 21:23:31 | cdent | yeah, so always bionic | |
| 21:23:36 | mriedem | yup | |
| 21:23:41 | mriedem | do we want to skip the test for now? | |
| 21:23:58 | cdent | if you're happy with that, that's probably the easiest way to go | |
| 21:24:47 | mriedem | or at least skip on py36 | |
| 21:25:09 | sean-k-mooney | python 3.6 will be the defult on rhel8 also as per doug hellmann's mail earilier today | |
| 21:26:02 | cdent | yeah, I'll do a skipIf | |
| 21:26:09 | cdent | one moment please | |
| 21:26:42 | sean-k-mooney | im testing with Python 3.6.5 on centos 7 and it passed | |
| 21:27:56 | cdent | yeah, that's expected | |
| 21:28:31 | sean-k-mooney | oh it needs to be 3.6.7+ to fail | |
| 21:43:14 | openstackgerrit | Chris Dent proposed openstack/nova master: Skip double word hacking test https://review.openstack.org/618843 | |
| 21:43:21 | cdent | mriedem, efried, sean-k-mooney ^ | |
| 21:44:24 | sean-k-mooney | is that really a nova bug or a hacking bug? | |
| 21:45:06 | cdent | the failing test is because of changes to the tokenize stdlib. The hacking check is in nova itself, not in hacking | |
| 21:45:20 | sean-k-mooney | i guess we shoudl make the test support both the old and new api | |
| 21:45:24 | cdent | at least the way nova is experiencing the problem | |
| 21:45:46 | cdent | sean-k-mooney: I tried and failed to do that because it is in the guts of pep8 where the problem happens | |
| 21:45:50 | cdent | all hacking has is a regex | |
| 21:46:24 | cdent | the presence of the added NEWLINE token causes pep8 to believe it needs to make a logical instead of physical check | |
| 21:47:16 | sean-k-mooney | not sure i follow but then again i have not looked at the python bug yet | |
| 21:47:24 | cdent | there's little we can do from our side of the world to make it not add the NEWLINE | |
| 21:47:41 | cdent | looking at the python bug (and the related tracker for api breakages it causes) will make things much more clear | |
| 21:49:13 | sean-k-mooney | so just to be clear on what line in test_chesck_double_words is it addint the new line | |
| 21:49:17 | sean-k-mooney | the + operator | |
| 21:49:34 | cdent | at the end of the entire string | |
| 21:49:37 | cdent | and it isn't adding a new line | |
| 21:49:45 | cdent | it is adding a NEWLINE token when tokenizing | |
| 21:49:55 | sean-k-mooney | oh | |
| 21:50:13 | sean-k-mooney | that seams like a think it should not be doing... but ok | |
| 21:50:21 | sean-k-mooney | anyway you temp fix makes sense | |
| 21:50:33 | cdent | yeah, you'd think so, but someone decided that the method should behave more like C | |
| 21:50:48 | cdent | the comments on the python bug are amusing | |
| 21:50:49 | sean-k-mooney | c ends with \0 | |
| 21:50:56 | sean-k-mooney | e.g. a 0 byte | |
| 21:50:58 | sean-k-mooney | not a new line | |
| 21:51:20 | cdent | right, but it tokenizes a NEWLINE | |
| 21:51:21 | cdent | apparently | |
| 21:51:25 | sean-k-mooney | so it does not match c either in terms of string termination of const char* s | |
| 21:51:30 | cdent | it's not about string termination | |
| 21:51:34 | cdent | it is about code tokenizing | |
| 21:51:59 | cdent | please, read the bug | |
| 21:52:05 | cdent | it will all become clear | |
| 21:52:30 | sean-k-mooney | yes i was as we were chatting "As was pointed out in https://bugs.python.org/issue33766 there is an edge case in the tokenizer whereby it will implicitly treat the end of input as a newline." | |
| 21:53:45 | efried | cdent: What is [1] in the commit message? | |
| 21:54:02 | cdent | that link that sean-k-mooney just pointed at, did I forget to add it? le sigh | |
| 21:54:23 | efried | not https://bugs.python.org/issue33899 ? | |
| 21:54:39 | openstackgerrit | Chris Dent proposed openstack/nova master: Skip double word hacking test https://review.openstack.org/618843 | |
| 21:54:52 | cdent | argh too many bugs | |
| 21:55:39 | sean-k-mooney | efried: the openstack bug points to the python bug | |
| 21:55:48 | openstackgerrit | Chris Dent proposed openstack/nova master: Skip double word hacking test https://review.openstack.org/618843 | |
| 21:55:51 | sean-k-mooney | but yes the commit does not have a bug link | |
| 21:56:09 | sean-k-mooney | hehe ok now it does | |
| 21:56:12 | efried | so none of those is https://bugs.python.org/issue33766 | |
| 21:56:14 | cdent | there we go, now it links to the two python bugs I wanted to link to, neither of which are the one that sean pointed to (which was an originating bug) | |
| 21:56:16 | cdent | indeed | |
| 21:57:05 | efried | Not having dug any deeper, I'll point out that ``echo 'print("a");print("b")' > test.py`` does indeed end with a newline. | |
| 21:57:16 | sean-k-mooney | yes https://bugs.python.org/issue35107 is tracking the fallout of fixing https://bugs.python.org/issue33899 which ended up breaking backward compatiblity | |
| 21:57:33 | efried | efried@efried-ThinkPad-W520:~$ echo 'print("a");print("b")' > /tmp/test.py | |
| 21:57:33 | efried | efried@efried-ThinkPad-W520:~$ od -c /tmp/test.py | |
| 21:57:33 | efried | 0000000 p r i n t ( " a " ) ; p r i n t | |
| 21:57:33 | efried | 0000020 ( " b " ) \n | |
| 21:57:33 | efried | 0000026 | |
| 21:57:47 | cdent | i don't think that's the point efried | |
| 21:57:52 | efried | I'm sure it's not. | |
| 21:57:59 | efried | hence the 'not having dug any deeper' | |
| 21:59:11 | cdent | it's the same deal: discussion on that bug revealed the different between a newline character and a NEWLINE token and ways in which tokenizer failed to produce NEWLINE in some cirtical areas | |
| 21:59:16 | cdent | the fix, however, was too hasty | |