Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-16
16:25:41 dansmith hah
16:26:03 efried dansmith: I personally have no problem with {1, 2} set syntax. A set is a dict with only keys. And I don't have trouble distinguishing between commas and colons.
16:26:17 dansmith aight, well, that settles it then
16:26:26 artom " A set is a dict with only keys" Umm...
16:26:29 efried dansmith: but jaypipes expressed a distaste for it (for the same reasons) so I avoided it... until he was gone.
16:26:46 dansmith oh did he? damn, should have gotten my rule landed then
16:28:29 efried a) I think set((1, 2)) is overly verbose and unnecessary, b) my IDE warns that I should use a set literal, c) I believe set((1, 2)) is also less efficient because it first creates a tuple, then calls a method to turn it into a set.
16:29:34 efried obv b) I could ignore / turn off, and I'm sure c) is negligible in 99.99% of cases. But given aforementioned not-problem with the literal syntax, it's enough for me.
16:29:34 dansmith yeah, I don't like how verbose set() has to be, and yes there's some overhead but I think it's trivial in this case
16:30:05 dansmith ack
16:36:57 efried stephenfin: before I dig into that: I'm of the opinion that a) we should make it look like the other service API shims. nova/$service_type/$project_name.py; b) I don't see a need for a generic abstract API layer.
16:36:57 efried Is that what you've done?
16:41:17 sean-k-mooney dansmith: for what its worth i dislike {} as that allways meen a dict so i dont like useing it to initalise a default. i alway use set() if i want a set in that case
16:41:36 sean-k-mooney well if its empty that is
16:41:57 dansmith well, confirmation that I'm not crazy, at least
16:42:00 efried If set(1, 2) were allowed I would be less grouchy about it.
16:42:09 dansmith or.. "at least as crazy as sean-k-mooney" I guess :P
16:42:38 sean-k-mooney efried you have to do set({...}) right
16:42:41 efried but having multiple meanings for the same operator/punctuation doesn't bother me as long as it's clear from the context, which IMO it is in this case, because colons.
16:42:42 sean-k-mooney that is annoying
16:42:54 efried sean-k-mooney: set($iterable)
16:43:03 sean-k-mooney ya
16:43:16 efried so {...} if that's a set or a dict would work to get you a set of the keys; (...) for a tuple, [...] for a list etc.
16:43:16 dansmith stephenfin: same
16:43:31 sean-k-mooney stephenfin: becasue paython is annoying enough to parse as it is
16:43:51 efried I don't really get why that would be better; but I'm going to guess they chose {} because, as I said, a set is a dict without values.
16:43:59 sean-k-mooney <> i think is technically not equal in python 2
16:44:07 dansmith a set is not a dict with no values :)
16:44:16 stephenfin sean-k-mooney: indeed, it is
16:44:29 stephenfin I've seen that once in my life, I think
16:44:31 stephenfin (docutils)
16:44:41 efried dansmith: totally is. O(1) hashing, just no pointers out of the buckets.
16:44:51 dansmith sean-k-mooney: as hateful as they are, I can imagine them doing that in py3 to break compatibility for fun and profit.. I guess dict literals just got added too early :)
16:44:52 sean-k-mooney although i think its also the same as != and is checking identiy not equality but i might be wrong on that
16:45:07 dansmith efried: totally is not :)
16:45:38 dansmith it may be the same implementation under the covers, but that does not make the statement true :)
16:47:58 efried nova-live-migration seems to be ill. Anyone available to dig in?
16:53:40 dansmith I would think artom would be a good person to maybe start taking on some responsibility for that stuff given his numa LM work
16:54:05 dansmith building some context for the future and what not
16:54:54 sean-k-mooney i got landed with some downstream stuff but in theory i am ment to be helping porting those jobs to be non legacy too
16:55:27 sean-k-mooney efried: is it blocking ci or just starting to fail more then we would like
16:55:56 efried sean-k-mooney: It has tanked many patches in CI in the last 18h or so.
16:56:05 efried doesn't seem to be 100%, but it's close.
16:56:17 efried I haven't looked into it at all because I haven't yet been bothered to f'ing unzip the logs.
16:56:35 sean-k-mooney has my patch merged to fix that yet
16:56:46 sean-k-mooney you rechecked it this morning/last night right
16:57:04 efried your patch did merge, yes. Not sure if any of the failed jobs started since then.
16:57:05 sean-k-mooney ya looks like it di
16:57:52 efried I don't even know if the failures are the same across the board. I just know many have been failing. (Most of the nova-next failures are due to 'multiple possible networks', which I'm fixing elsewhere.)
16:58:24 sean-k-mooney yes with your tempest patch
17:00:14 sean-k-mooney that should also be merged now. if no one else fixes it ill try and get though these backprots then i can look at ci but proably tomorow or monday.
17:08:07 efried stephenfin: +2 on https://review.opendev.org/#/c/696745/
17:08:07 efried I guess controversy was in previous versions.
17:08:07 efried I get the gripe about making backports difficult, but the code base will just get messier and messier if we don't bite the bullet and clean this stuff up from time to time.
17:08:07 efried Besides, I don't see backports being hugely affected by this.
17:08:07 efried So ++
17:08:23 stephenfin thanks
17:26:46 efried I can't even see why https://zuul.opendev.org/t/openstack/build/093f129de3ca47549239eed0d6acf288 is failing. The job output says devstack failed, but the devstack log looks okay to me. Anyone? Bueller?
17:29:48 efried /opt/stack/new/devstack/lib/databases/mysql: line 64: mysql: command not found
17:29:48 efried ^ on the subnode. wtf?
17:30:06 artom Wait, that .gz compression thing hasn't been fixed?
17:30:28 efried artom: sean-k-mooney fixed it somewheres, but this job may have started before that fix merged.
17:30:30 efried Real PITA.
17:30:39 artom Seriously, wit hummus.
17:30:56 efried mm, hummus.
17:31:41 sean-k-mooney artom: https://review.opendev.org/#/c/702465/ meged this morning
17:32:06 sean-k-mooney but if the job started before that merged then ya they would be compressed
17:32:22 artom sean-k-mooney, were they not gziped but transparently decompressed before?
17:32:34 sean-k-mooney yes
17:32:42 sean-k-mooney well no
17:32:50 artom So what killed the transparent decompression?
17:32:56 sean-k-mooney they were gzip and serve with hearders to decompress them
17:33:01 sean-k-mooney but that had issues with swift
17:33:06 artom Oh, the browser did it
17:33:11 artom Client-side
17:33:34 sean-k-mooney yes the borser did but the issue is they were getting double compressed wehn being served form swift
17:33:47 sean-k-mooney so that is why you see the garbage in your browser
17:34:12 artom Oh, does Swift automagically compress text or something?
17:34:14 sean-k-mooney it is still decompressing with deflate but not then decompressing that with gzip
17:34:41 openstackgerrit Vladyslav Drok proposed openstack/nova master: Make removal of host from aggregate consistent https://review.opendev.org/696392
17:34:44 sean-k-mooney artom: i did not look into it fully but fungi would be able to actully explain it
17:35:11 sean-k-mooney artom: for now just do curl <url> | zcat | less
17:35:24 sean-k-mooney or lnav lnav is good
17:35:49 artom I want to make a `squat` and `rack` command
17:35:58 artom So I can squat | curl | rack
17:38:37 sean-k-mooney looking at the log failrue we are getting nova warning for using deprecated version of qemu and libvirt
17:39:04 fungi sean-k-mooney: we're not clear whether it's a behavior in rackspace's swift implementation or the cdn they put in front of it, but if we upload .gz files with a content-type of application/gzip then they will be transparently decompressed when browsers or other clients request them and indicate they accept that content-type. sounds convenient, right? until you save a .tar.gz file there and it's
17:39:06 fungi quietly decompressed on retrieval without altering the extension, so you've downloaded a file whose name claims it's a gzipped tarball but which is in reality now an uncompressed tar archive. now make that an intermediate step in a release publication job and you're pushing python sdists or similar tarballs somewhere when they're not actually installable (because tools think they're compressed when
17:39:08 fungi they're not)
17:40:41 fungi so we altered the way we store job artifacts in swift to make it so that we transparently compress everything on upload, unless it's already a compressed file, and assume that if the file has been precompressed then it should not be transparently decompressed for requesting clients
17:40:47 fungi artom: ^
17:42:06 efried clearly fungi has had to explain this before :P
17:42:20 artom fungi, to be honest I didn't grok most of that. My takeaway is: layers do deep even onions are like "whoa dude"
17:42:23 sean-k-mooney yes
17:42:29 artom *so deep
17:42:54 sean-k-mooney but thanks for the explaination again.
17:43:53 fungi we fixed the obvious cases we knew about in abstract jobs/roles but there were some in devstack which had to get fixed too
17:44:16 sean-k-mooney fungi: funnialy enogh the last time i tried deploying zuul at home geting the logs to render properly in the bower when loadbalnace via nginx in k8s was actully one of the hardest parts
17:44:21 fungi and there are also some project-specific jobs which are also precompressing logs from things which will need to be adjusted to stop compressing within the job
17:44:42 fungi which should be updated as we encounter them

Earlier   Later