| *** thecorconian [~thecorcon@136.1.1.104] has joined #baserock | 01:23 | |
| thecorconian | good evening. just letting you know that jte has joined the room. | 01:24 |
|---|---|---|
| *** thecorconian [~thecorcon@136.1.1.104] has quit [Remote host closed the connection] | 02:57 | |
| petefoth | persia: Generally I think fixing docs should go hand-in-hand with fixing / simplifying / specifying workflows. | 06:42 |
| petefoth | in the csae of the 'relative paths' issue I could trawl through w.b.o. If paulsherwood has fixed some / most / maybe all of them already, thenther may be little benefit. I'll create a Kanban card and we can decide at the planning meeeting whetjer ti shoyuld get actioned any time soon | 06:44 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:00 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:47 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:48 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:53 | |
| straycat | If we ran all extensions by default would we want to move all extensions to definitions to make sure the build doesn't unnecessarily depend on a particular version of morph? | 09:26 |
| persia | The build inherently depends on a particular version of morph anyway. | 09:27 |
| persia | Or rather, a sufficient set of aspects of morph that we don't have a way to track them independently. | 09:27 |
| persia | For discovery, I'd rather have all the configuration extensions in one place, but don't have an opinion on what place that ought be. | 09:28 |
| straycat | Okay so in your opinion it doesn'tmatter. | 09:28 |
| persia | For the purpose you state, yes (although I like the idea of consolidating for other reasons). | 09:28 |
| *** liw-orc [~liw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:29 | |
| persia | Note that if we run all the configuration extensions by default, we also need to consider the impact on reproducibility: if the set of configuration extensions changed between one build and another, the system could change. | 09:29 |
| straycat | Welcome back liw-orc :) | 09:29 |
| straycat | persia, That sounds like an argument for keeping all the extensions in definitions? | 09:30 |
| persia | Like I said, I like your proposal for other reasons, just not the one you stated :) | 09:31 |
| * straycat nods | 09:32 | |
| pedroalvarez | but, the extensions are for deploying, not for building | 09:33 |
| persia | pedroalvarez: Yes, but if you can't deploy the system in the same way twice, you don't have the same result when you test it. | 09:34 |
| straycat | Okay cool, I'll try to write a patch for this this week | 09:36 |
| persia | straycat: Thanks! | 09:36 |
| straycat | Oh, also, can we run Baserock natively yet? | 09:40 |
| richard_1aw | straycat: I can lend you a USB stick which you can boot from, but we don't yet have an installer | 09:41 |
| * straycat apologises in advance for his dumb questions | 09:41 | |
| richard_1aw | if you want to run Baserock on a PC | 09:41 |
| richard_1aw is now known as richard_maw | 09:41 | |
| persia | Another option is to deploy with initramfs to RAW, and dd the RAW to a fixed disk, install that, and boot (not prettiest, but should work). | 09:42 |
| straycat | Right | 09:43 |
| straycat | okay cool thanks | 09:43 |
| persia | richard_maw: Out of curiosity: did you ever test upgrade against the USB stick? | 09:48 |
| richard_maw | persia: no, because I don't have a fast enough USB stick that I'd have the patience to sit through it, but I'm fairly confident it would work. | 09:49 |
| * ssam2 discovers CirrOS https://launchpad.net/cirros | 09:50 | |
| ssam2 | seems to be another minimal Linux/Busybox OS intended for cloud use | 09:50 |
| persia | richard_maw: heh. Maybe I'll try it overnight sometime. Is there some trick to initialising the USB? | 09:50 |
| ssam2 | built using buildroot | 09:50 |
| persia | ssam2: My understanding is that CirrOS is mostly used as a demo environment when testing cloud infrastructure, rather than being expected to carry an application payload, although I may be mistaken. | 09:51 |
| ssam2 | persia: ah, OK. I discovered it while testing cloud infrastructure, so that seems plausible :) | 09:52 |
| persia | Let me guess: you noticed the default image preregistered in glance :) | 09:52 |
| ssam2 | indeed | 09:52 |
| persia | cubswin:) | 09:52 |
| ssam2 | how did you know my password ??? | 09:52 |
| persia | ;) | 09:53 |
| petefoth | redsoxloseagain :( | 09:53 |
| persia | pedroalvarez: Except sometimes the Sox get a pennant. | 09:54 |
| franred | patch to update definitions sent to the mailing list - just add a change made in cpython.morph | 09:54 |
| petefoth | persia: and the occasional World Series | 09:55 |
| straycat | franred, that patch you just sent, is that deliberately reverting a change Kinnison made the other week? | 10:48 |
| * persia read it as moving the change from the chunk repo to the definitions repo | 10:48 | |
| franred | straycat, it is deliverately adding richard_maw's changes to reflect them in definitions repo | 10:49 |
| persia | But if it's the other way, that underscores the need to drop the repo morphologies when changing things. | 10:49 |
| straycat | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=ebfcbd166dfe49c6632d0aeeb6d2050a4d507576 ? | 10:50 |
| straycat | Feel free to ignore me if I'm in error, I'm still not awake >.> | 10:51 |
| franred | straycat, ugh... I though it was in the other way around - sorry | 10:51 |
| * persia is now confused and refrains from having an opinion in this area | 10:51 | |
| franred | persia, it was my fault thinking that the chunk in its repo was the one which was updated - so I made the patch in this way. As straycat correctly said, this revert a previous correct patch. | 10:57 |
| persia | Does definitions still point at a ref that contains a chunk morphology? | 10:57 |
| franred | at some point we should rid off all definitions in repositories to avoid this confusion | 10:57 |
| franred | persia, definitions is fine AFAIK | 10:58 |
| persia | Does definitions still point at a ref that contains a chunk morphology? | 10:58 |
| pedroalvarez | they are pointing to the same ref that were pointing before moving them to definitions.git | 11:03 |
| persia | In that case, ebfcbd166dfe49c6632d0aeeb6d2050a4d507576 was incomplete: it should have also changed the ref to something not including the chunk morphology. | 11:04 |
| persia | We should watch for that when reviewing morphology changes. | 11:04 |
| pedroalvarez | but we didn't want to trigger a full rebuild | 11:04 |
| persia | Then something is deeply broken. | 11:04 |
| persia | If changing the ref causes a rebuild, but changing the chunk morphology doesn't, then we have no means to confirm that our artifacts match our definitions. | 11:05 |
| persia | (because it's possible to game things in ways that don't cause rebuilds when they should happen) | 11:05 |
| * persia had thought the entire contents of the post-processed chunk morphology was part of the cache key, and is very disturbed to discover this can be gamed | 11:06 | |
| pedroalvarez | persia: changing the chunk morphology does causes a rebuild, why do you think it won't? | 11:06 |
| persia | Because you said you didn't want to trigger a full rebuild. | 11:06 |
| persia | Which implies one didn't happen, which means things that depend on the changed chunk have no means of ensuring they still work at all. | 11:07 |
| pedroalvarez | persia: if we change the ref of the chunk morphology to point to a different place in which there are not chunk morphologies, it will rebuild/. | 11:07 |
| persia | Good. | 11:07 |
| persia | Does it also rebuild if you change the text of the chunk morphology in definitions? | 11:08 |
| persia | And do both rebuilds properly cause a rebuild of all reverse build dependencies? | 11:08 |
| pedroalvarez | moving the chunks morphologies to definitions didn't trigger any rebuild because the chunk morphologies used to build a sha1 of a repo were the same | 11:08 |
| persia | Good. | 11:08 |
| persia | To make sure, are we both talking about ebfcbd166dfe49c6632d0aeeb6d2050a4d507576? | 11:09 |
| pedroalvarez | :) let me read backscroll | 11:10 |
| * pedroalvarez is now researching the status of the cpython repository, and the sha1 we are using | 11:15 | |
| pedroalvarez | oh | 11:22 |
| pedroalvarez | I was confused because the same commit also changes the sha1 of morph | 11:22 |
| pedroalvarez | ok, now I am full of context | 11:23 |
| persia | Right, but I think it should have also changed the SHA of cpython, and that it didn't was a review failure. | 11:23 |
| persia | Not a major one, but we should be more careful in future. | 11:23 |
| pedroalvarez | I agree | 11:23 |
| pedroalvarez | someone was looking at creating a script to remove all of them at once | 11:24 |
| persia | Yes, paulsherwood mentioned that a couple times. I don't think we ought wait on that though, but *also* do per-repo updates as they happen. | 11:24 |
| persia | If the script is good, it won't break in this situation. | 11:25 |
| persia | franred: Based on pedroalvarez and my agreement on context, would you want to update your patch to do that, or should one of us send the fix to complete ebfcbd166dfe49c6632d0aeeb6d2050a4d507576 ? | 11:25 |
| pedroalvarez | the fix shold be: change the ref of python to point to somewhere without chunk morphology | 11:26 |
| pedroalvarez | s/python/cpython/ | 11:26 |
| richard_maw | can I get some quick eyes on http://pastebin.com/mNCPzjdS ? | 11:27 |
| persia | This is probably the parent of the current ref, but needs testing, etc. | 11:27 |
| richard_maw | for context see: [BUG] Morph edit can not edit linux chunk with current morph master | 11:27 |
| persia | richard_maw: Could we also add a test to catch this situation in the future? | 11:28 |
| persia | (the patch looks sane, but without that, we may encounter the bug again) | 11:28 |
| richard_maw | persia: the mail discusses how this could be avoided in future | 11:29 |
| pedroalvarez | persia: probably. This makes me wonder if we care about using a sha1 which is not the HEAD of the unpetrify-ref. If we can use upstream tags as unpetrify-ref, if we should create baserock/foo branches, etc | 11:29 |
| persia | richard_maw: Sorry: lack of context: I was responding only to your paste. | 11:29 |
| liw-orc | richard_maw, looks OK to me, but I lack context having been away for two weeks; +2 if you're sure it works | 11:30 |
| richard_maw | persia: my preferred solution is to spawn a git daemon in each scenario to act as the git server | 11:30 |
| richard_maw | so the tests are behaving closer to reality | 11:30 |
| persia | pedroalvarez: I don't understand the benefit purportedly provided by unpettrify-ref, as it's trivial to cause it to have a useless or incorrect value. Someone would need to explain this to me before my response would be more complicated than "just drop unpetrify-ref entirely then". | 11:31 |
| persia | richard_maw: That makes sense: so this is just a temporary fix, and a more complicated one comes later? | 11:31 |
| richard_maw | persia: this is a permanent fix to the bug, it is not a fix for the coverage hole | 11:32 |
| persia | pedroalvarez: As a thought experiment, consider the case where I check out the unpetrify ref in a bare git repo somewhere, add a commit, and push. | 11:32 |
| richard_maw | persia: I intend to patch the coverage hole soon | 11:32 |
| persia | richard_maw: Yes, we're using different words and/or different meanings for the same words to convey the same intent. | 11:32 |
| persia | I'm happy with this as the beginning of a solution, but do want the coverage hole also fixed. | 11:33 |
| persia | (or to be rendered irrelevant by other changes) | 11:33 |
| pedroalvarez | persia: we do that every day | 11:34 |
| franred | persia, my patch is wrong. we need to submit a patch which fix the error which is what pedroalvarez has suggested | 11:35 |
| persia | franred: Right: do you want to do that, or should someone else? | 11:36 |
| pedroalvarez | franred: can you? | 11:36 |
| persia | pedroalvarez: If you do that every day, then it's not uncommon that unpetrify-ref HEAD usually doesn't match ref in most definitions repos, so don't worry about it. | 11:36 |
| franred | pedroalvarez, persia, Im quite busy now, but I take a note an do it later | 11:37 |
| pedroalvarez | persia: but I usually want that sha1 pointing to the HEAD of unpetrify-ref | 11:38 |
| persia | pedroalvarez: If you want that in a consistent way and always up to date, just use the branch ref as ref. | 11:40 |
| persia | If you want a particular SHA, you probably don't care if it happens to be HEAD somewhere, because you don't want to consume other folks changes unintentionally. | 11:40 |
| paulsherwood | richard_maw: there was a lot of discussion about the git replace here yesterday - did you read the backscroll? | 11:54 |
| paulsherwood | i contended that the basis of your original patch may be unsafe, and proposed that it be reverted until we fully understand the implications | 11:55 |
| richard_maw | hm, I'll see if it's still in my scroll buffer | 11:57 |
| * persia is reminded | 12:00 | |
| persia | Do we have any irc log bots that are known to run in Baserock? Does anyone know how to configure them? | 12:00 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 12:01 | |
| richard_maw | persia: not to my knowledge | 12:02 |
| persia | pity. It would be handy to have posted logs in case the buffers are inadequate. In any case, if yours is not old enough, I can send you a longer one. | 12:03 |
| richard_maw | I've got it in my history, so you don't need to send me it | 12:03 |
| richard_maw | re: possibly breaking previous builds, no upstreams of Baserock are using refs/replace, or have they ever while we were mirroring their repositories, since we don't delete their refs by default | 12:07 |
| persia | We've checked that? In that case, I agree that the patch isn't unsafe. | 12:08 |
| richard_maw | persia: I did a quick check before I submitted the patch, and I did a more extensive one just now | 12:09 |
| persia | Cool. Thanks for that. | 12:10 |
| richard_maw | re: supporting upstreams that _do_ use refs/replace: it is possible, without spurious rebuilds, by changing how we check out the working trees to be something we can instrument, so we can list which replacement refs are used | 12:10 |
| persia | The plan documented in your commit message? | 12:11 |
| richard_maw | yes | 12:11 |
| persia | Right. I think the main concerns were 1) the issue for which you asked for paste review earlier and 2) that some upstream might be using this already and our disabling it could cause issues. | 12:11 |
| persia | WIth 1) resolved by the patch, and 2) resolved by investigation, I think it's now safe to not revert, but from a process perspective, I wonder if the change was reviewed properly, that we do fixup today. | 12:12 |
| * paulsherwood is ok with this | 12:14 | |
| paulsherwood | thank you | 12:14 |
| richard_maw | It was not reviewed sufficently, I just got a blanket +2 from Daniel, since he understood the implications immediately. I trusted the test suite to have covered everything I changed, but the file:// URI thing was a failing I didn't anticipate. | 12:17 |
| richard_maw | I'm sorry I left master broken | 12:17 |
| paulsherwood | as persia said, only a few bleeding edge users could have noticed. my main concern was the possibility that we could be starting to deliberately ignore what upstream wants | 12:18 |
| richard_maw | people seem to use git replace as a way to splice git histories to look nicer, so it's very unlikely that anyone would use it for changing the trees associated with the commits, but I can think of a couple of uses for it | 12:21 |
| paulsherwood | i still don't understand the implications properly, tbh. if upstreams *did* start using replace in future, what would happen in baserock workflows/systemss? | 12:23 |
| richard_maw | 1. inserting expunged secret data, so you can only access the keys if you fetch the refs/replace from some other repository that you can access | 12:26 |
| richard_maw | 2. a weird workflow where you only push commits per-release, but work-in-progress is pushed as a refs/replace of HEAD^{tree} | 12:27 |
| richard_maw | paulsherwood: if they *did* start using replace for valid reasons, we'd have to undo the change to ignore refs/replace and include information about which refs/replace were used in checking out the commit in the cache key | 12:28 |
| persia | I suspect that with the strategy for this documented in the latest commit, this would be relatively simple. | 12:29 |
| richard_maw | at which point it pretty much works the same as before, but we need to have `morph checkout` include the replacement refs in the local checkout, or we'd get different results at build-time to development time | 12:30 |
| richard_maw | persia: simple would be to include every ref in refs/replace | 12:30 |
| persia | richard_maw: And regarding leaving master broken: thank you for not pushing the change to definitions, so only folk hacking on morph noticed. | 12:30 |
| paulsherwood | richard_maw: i mean, as a *user* what will happen? will i notice? will my systems still build? will i still be building what upstream intends? | 12:30 |
| persia | richard_maw: That's what I was thinking, but I lacked confidence in my understanding of git internals. | 12:30 |
| richard_maw | paulsherwood: it does have implications for reproducible building | 12:30 |
| richard_maw | since you have to have a way to select which replacement refs to include in your build | 12:31 |
| *** thecorconian [~thecorcon@136.1.1.104] has joined #baserock | 12:32 | |
| richard_maw | my preferred solution would be to explain why `git replace` is a bad idea to any upstream that decides to use them for anything but history splicing | 12:32 |
| paulsherwood | could we discuss with git upstream? maybe get replace deprecated? | 12:33 |
| paulsherwood | or at least publish the concerns, get discussion going? | 12:34 |
| richard_maw | I'd be happy with the `git replace` command refusing to do so for anything that isn't a commit, and tweaking checkout to refuse replacements anywhere except `git log` | 12:36 |
| persia | That would probably be a useful discussion to have upstream. | 12:40 |
| thecorconian | good morning. just letting you know that jte has joined the room. | 12:43 |
| paulsherwood | thecorconian: long time no see :) | 12:43 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:45 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:46 | |
| richard_maw | persia: I'll make a note to raise it tomorrow, along with making the test suite simulate a git server better | 12:56 |
| persia | richard_maw: Sounds perfect. Thank you. | 13:00 |
| richard_maw | hm, git.baserock.org's git-daemon has spawned too many children again. | 13:16 |
| persia | Do we know what causes this? | 13:16 |
| richard_maw | at a guess: the git upload-pack processes not terminating correctly, I'll give it 5 minutes to see if I can work out why, otherwise I'm going to restart the daemon | 13:18 |
| richard_maw | hm, no logs for anything before sunday | 13:22 |
| richard_maw | but we've only had failures today | 13:23 |
| richard_maw | hm, that's interesting; all the stuck processes are morph | 13:28 |
| richard_maw | well, they're all upload-pack processes for the morph repository | 13:28 |
| persia | Hmm. I wonder if we shouldn't stop doing development directly against g.b.o, and just lorry morph like everything else. | 13:29 |
| persia | That said, it's probably useful to fix the actual problem :) | 13:29 |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:37 | |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:37 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 13:38 | |
| *** flatmush1 [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:39 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:39 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:39 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:39 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 13:39 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:39 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 13:39 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:39 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:39 | |
| franred_ | I've seen that we use nss and nspr for ceph systems, could I put those chunks in a shared strata morphology like webtools? or should I create a Network-security-service strata which includes them? | 13:53 |
| persia | If we're using webtools for both gerrit and ceph, putting them in a shared stratum makes sense. I think we should strive for as few strata as possible, but acknowledge that as the number of different sorts of systems being prepared expands we expect the number of strata to grow extensively. | 13:54 |
| paulsherwood | +1 | 13:54 |
| franred_ | umm, sorry I think I've created confusion, webtools are not in ceph-services.morph . nss and nspr are chunks of ceph-services.morph. Because nss are "Network-Security-Service" and nspr "Netscape Portable Runtime", I wonder what was the correct place to put them to share between strata, so I was thinking on webtools | 13:59 |
| franred_ | ? | 13:59 |
| paulsherwood | it's ok for now | 14:01 |
| persia | If you need to share components, and there's no current common stratum, create a new one | 14:03 |
| franred_ | persia, yes, I think this is going to be the case | 14:04 |
| franred_ is now known as franred | 14:04 | |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 14:05 | |
| richard_maw | I failed to debug what happened to git.baserock.org's git-daemon, so I restarted it. Perhaps next time it happens will have been recent enough that there'll be logs | 14:12 |
| liw-orc | richard_maw, did you restart it just now? | 14:13 |
| richard_maw | yes | 14:13 |
| persia | Is there a way we can capture the problem before it becomes unusable? | 14:13 |
| richard_maw | persia: not sure; we can set timeouts, but that could cause spurious failures for clones that would eventually finish, rather than ones that get stuck | 14:15 |
| richard_maw | we can also change the subprocess limit, so it happens quicker, so we can debug it, or turn off the limit | 14:15 |
| persia | I was rather thinking of some periodic job that calculated some metric (e.g. how many are stuck), and notifed someone when it got above a threshold (preferably before operational failure) | 14:16 |
| persia | Essentially, small shell script in a 5-minute cronjob or similar. | 14:16 |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:18 | |
| richard_maw | `test "$(wc -l </sys/fs/cgroup/systemd/system/git-daemon.service/cgroup.procs)" -lt 16` would be the important check here I think | 14:22 |
| persia | And once it hit 16, we ought be able to troubleshoot the problem while it is active? | 14:23 |
| richard_maw | and give some wiggle room to see if we can introduce more stuck processes to see what causes it | 14:26 |
| richard_maw | but we could also include output from `journalctl -u git-daemon.service` to see if that enlightens us | 14:27 |
| persia | Doing both every few minutes sounds like a good plan. | 14:29 |
| persia | Seems it needs restarting every week or two, which can be annoying. | 14:29 |
| richard_maw | worse than that, I had to give it a kick last friday | 14:29 |
| persia | Oh my! | 14:30 |
| richard_maw | recent changes that may be related: 1. we've got CI pipelines running, though the only one of those that should be related is the firehose one, which may be testing merges of morph | 14:33 |
| richard_maw | 2. we now do a ls-remote before building to see if we have unpushed changes | 14:34 |
| flatmush1 is now known as flatmush | 14:45 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:18 | |
| ssam2 | franred points out that we currently save openstack passwords in plaintext in morph.log :( | 16:30 |
| ssam2 | we should fix that soon if we are going to be making more use of OpenStack ! | 16:30 |
| persia | We should also fix the annoyance that one has to specify the password on the morph deploy command line: the normal OpenStack environment variable is not honoured. | 16:36 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:36 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 16:36 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 16:36 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 16:36 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:36 | |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 16:37 | |
| liw-orc | it's unfortunate that OpenStack requires having passwords in cleartext anywhere | 16:37 |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:37 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:37 | |
| persia | It doesn't actually, but not doing it that way is annoying. | 16:37 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:37 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:37 | |
| * persia would prefer it if keystone honoured SSL certs for authentication. | 16:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:38 | |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:39 | |
| ssam2_ | if anyone spoke in the past few minutes, our rather crappy ADSL probably prevented me from hearing it | 16:39 |
| ssam2_ | I was going to point out our current, rather lame solution for filtering out passwords in /baserock/deployment.meta: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/plugins/deploy_plugin.py#n564 | 16:40 |
| ssam2_ | we could add this to the logging of environment variables, as a quick fix | 16:40 |
| *** thecorconian [~thecorcon@136.1.1.104] has quit [Quit: Leaving.] | 16:41 | |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:42 | |
| *** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:43 | |
| *** flatmush1 [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Disconnected by services] | 16:44 | |
| flatmush1 is now known as flatmush | 16:44 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 16:44 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 16:44 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 16:45 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 16:45 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:45 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:45 | |
| persia | ssam2: That would help in the short term. Longer term, we probably want to fix the root issue, so that we're not transmitting passwords insecurely. | 16:49 |
| *** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:53 | |
| *** thecorconian [~thecorcon@136.1.1.102] has joined #baserock | 17:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving.] | 17:35 | |
| *** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:46 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:46 | |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:48 | |
| *** thecorconian [~thecorcon@136.1.1.102] has quit [Remote host closed the connection] | 18:08 | |
| *** thecorconian [~thecorcon@136.1.1.102] has joined #baserock | 18:09 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 255 seconds] | 22:23 | |
| *** richard_1aw [~richard_m@xvm-21-133.ghst.net] has joined #baserock | 22:24 | |
| *** JPohlmann [~jannis@m65s13.vlinux.de] has joined #baserock | 22:24 | |
| *** JPohlmann [~jannis@m65s13.vlinux.de] has quit [Changing host] | 22:24 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock | 22:24 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 240 seconds] | 22:44 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 22:45 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 23:03 | |
| *** thecorconian [~thecorcon@136.1.1.102] has quit [Quit: Leaving.] | 23:16 | |
| *** thecorconian [~thecorcon@136.1.1.102] has joined #baserock | 23:25 | |
| *** thecorconian [~thecorcon@136.1.1.102] has quit [Quit: Leaving.] | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!