| *** elevenarms [~elevenarm@58.251.146.236] has joined #baserock | 00:46 | |
| *** elevenarms [~elevenarm@58.251.146.236] has quit [Quit: Be back later ...] | 01:30 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 250 seconds] | 03:44 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:11 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 08:19 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 08:19 | |
| De|ta_ is now known as De|ta | 08:54 | |
| *** elevenarms_ [~elevenarm@43.249.128.153] has joined #baserock | 08:55 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:04 | |
| *** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:08 | |
| *** elevenarms__ [~elevenarm@183.38.151.176] has joined #baserock | 09:15 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:16 | |
| *** elevenarms_ [~elevenarm@43.249.128.153] has quit [Ping timeout: 264 seconds] | 09:19 | |
| *** elevenarms___ [~elevenarm@43.249.128.217] has joined #baserock | 09:24 | |
| *** elevenarms__ [~elevenarm@183.38.151.176] has quit [Ping timeout: 252 seconds] | 09:24 | |
| petefoth | Is it the case that Baserock python code should follow PEP 8 - Style Guide for Python Code? If so, should we run the pep8 - Python style guide checker as part of our automated testing? And / or should we encourage contributors to use it themselves *before* submitting patches? | 09:26 |
|---|---|---|
| *** elevenarms____ [~elevenarm@103.27.226.34] has joined #baserock | 09:26 | |
| *** elevenarms___ [~elevenarm@43.249.128.217] has quit [Ping timeout: 244 seconds] | 09:29 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:31 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:32 | |
| SotK | Morph definitely follows PEP8, and its test suite checks that it does (`./check --style`). | 09:34 |
| SotK | Although having said that it doesn't seem to run the pep8 style checker, rather a script of our own. | 09:35 |
| petefoth | SotK: that’s alright then. I will add something to the ‘contributing’ wiki page | 09:35 |
| petefoth | SotK: oh - your second post is sad. Why not use pep8? Is our script better? | 09:36 |
| *** elevenarms_____ [~elevenarm@183.38.151.176] has joined #baserock | 09:37 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:38 | |
| *** elevenarms____ [~elevenarm@103.27.226.34] has quit [Ping timeout: 250 seconds] | 09:40 | |
| *** elevenarms_____ [~elevenarm@183.38.151.176] has quit [Read error: Connection reset by peer] | 09:41 | |
| SotK | petefoth: I don't know. Looking through the git history it looks like it just grew up over time as people thought of things to check for. | 09:41 |
| *** elevenarms_____ [~elevenarm@121.15.111.206] has joined #baserock | 09:41 | |
| *** elevenarms_____ [~elevenarm@121.15.111.206] has quit [Ping timeout: 256 seconds] | 09:46 | |
| *** elevenarms_____ [~elevenarm@64.9.146.198] has joined #baserock | 09:47 | |
| petefoth | Any thoughts on this question from yesterday: | 09:50 |
| petefoth | 13:32 < petefoth> where a write extension allows an UPGRADE parmeter, will morph deploy fail if no VM already exists at the specified location, or will it go ahead and create a new VM? | 09:50 |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Read error: Connection reset by peer] | 09:54 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09:54 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:57 | |
| Mode #baserock +v ssam2 by ChanServ | 09:57 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:06 | |
| *** elevenarms______ [~elevenarm@64.9.146.206] has joined #baserock | 10:15 | |
| *** elevenarms_____ [~elevenarm@64.9.146.198] has quit [Ping timeout: 272 seconds] | 10:16 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 10:17 | |
| straycat | petefoth, it should fail | 10:17 |
| straycat | from what i can see it will fail | 10:17 |
| straycat | each check ext seems to check and fail if there's not an existing system | 10:17 |
| petefoth | straycat: thanks. I looked at some of the write extensions, but not the check extensions | 10:18 |
| pedroalvarez | iirc only 2 of them allow an upgrade | 10:22 |
| pedroalvarez | rawdisk and ssh-rsync | 10:22 |
| petefoth | pedroalvarez: Indeed - from what I can see you use ssh-rsync to upgrade OpenStack, KVM and vbox-ssh VMS | 10:25 |
| pedroalvarez | even jetson boards! :) | 10:26 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:31 | |
| bashrc | what kernel version is baserock on? | 10:38 |
| ssam2 | the current version of the definitions format doesn't make it easy enough to answer that :) | 10:41 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-x86_64-generic.morph | 10:41 |
| ssam2 | that shows we're using this commit, in x86_64: http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/commit/?h=d67a0e110187abd560a1de63fa172894a52839d5 | 10:42 |
| ssam2 | the history of that commit is pretty whacky so http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=d67a0e110187abd560a1de63fa172894a52839d5 doesn't make it clear which version that branch is based on either | 10:43 |
| robtaylor | ssam2: git describe is your friend | 10:43 |
| ssam2 | I don't have linux.git checked out anywhere, and it's not available in the web interface | 10:43 |
| ssam2 | but otherwise, it'd be handy | 10:44 |
| bashrc | does the morph format allow comments? If so it might be a good idea to add the vernel version as a comment along with the commit reference | 10:44 |
| robtaylor | i know for jetson bsp its 3.18-rc3 | 10:44 |
| bashrc | ok | 10:44 |
| robtaylor | bashrc: yeah i've long thought a comment with a git-describe would be useful | 10:44 |
| pedroalvarez | 3.15.0 for other architectures | 10:44 |
| pedroalvarez | but can be upgraded or downgraded in around 20 minutes as paulsher1ood has proven here: http://vimeo.com/110065776 | 10:47 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:53 | |
| ssam2 | anyone remember what the problem is when `morph build` gives 'ValueError: need more than 0 values to unpack' ? | 10:53 |
| ssam2 | I know I've seen it before but can't remember why | 10:53 |
| SotK | did you do git clone rather than morph checkout or branch to get your definitions repo? | 10:54 |
| ssam2 | no, but I think that's the reason I've seen it before | 10:55 |
| ssam2 | however, the config in baserock/baserock/definitions/.git/config is present this time | 10:55 |
| ssam2 | I guess I get to debug! | 10:55 |
| *** elevenarms______ [~elevenarm@64.9.146.206] has quit [Ping timeout: 272 seconds] | 11:33 | |
| *** elevenarms______ [~elevenarm@43.249.130.202] has joined #baserock | 11:33 | |
| * pedroalvarez has accidentaly upgraded a baserock system with the combination of installer.py + rawdisk.write | 11:38 | |
| pedroalvarez | this is: running an installer system to upgrade your current baserock system instead of deploying a new one | 11:39 |
| ssam2 | did it work? | 11:39 |
| pedroalvarez | yes | 11:39 |
| pedroalvarez | as expected :) | 11:39 |
| pedroalvarez | well, it worked on the same way as a rawdisk upgrade | 11:44 |
| pedroalvarez | I'm not sure if we can call this "upgrade" | 11:44 |
| *** elevenarms______ [~elevenarm@43.249.130.202] has quit [Ping timeout: 244 seconds] | 11:50 | |
| *** elevenarms______ [~elevenarm@121.15.111.206] has joined #baserock | 11:50 | |
| *** elevenarms______ [~elevenarm@121.15.111.206] has quit [Ping timeout: 250 seconds] | 11:55 | |
| *** elevenarms______ [~elevenarm@64.9.130.191] has joined #baserock | 11:55 | |
| persia | Did the combination of installer.py+rawdisk.write applied to a system cause that system to have multiple entries for system-version-manager to parse? | 12:16 |
| persia | If so, call it an upgrade. If not, should this be supported? | 12:16 |
| * persia is thinking about the possibility of sneakernet upgrades | 12:16 | |
| pedroalvarez | IIRC what how I implemented system-version-manager, yes, that command will show multiple entries | 12:17 |
| pedroalvarez | the main difference that I see between this upgrade and the normal one (using ssh-rsync) is that we don't merge /etc nor /var | 12:19 |
| persia | Then why isn't it an "upgrade"? | 12:19 |
| persia | Ah. We should probably detect that condition, and do so. | 12:19 |
| persia | Or rather, detect it when the deployment was an upgrade, and overwrite (so system-version-manager does *not* show multiple versions) when the deploy was not an upgrade. | 12:19 |
| pedroalvarez | if the deployment (deployment to an stroage device usign rawdisk.write extension) is not an upgrade, it will overwrite everything | 12:21 |
| ssam2 | I guess it's hard to run system-version-manager in this type of upgrade, because we may not be able to execute binaries | 12:22 |
| ssam2 | actually 'system-version-manager deploy' only needs Python and shell so it might be possible | 12:22 |
| persia | ssam2: Why not? | 12:22 |
| ssam2 | but might not be worth doing | 12:22 |
| ssam2 | persia: if you're accessing a raw disk image from another machine I don't think it's a good idea to make an assumption about the architecture of the system inside the disk image | 12:23 |
| persia | A possible use case: a manufacturer of a disconnected device wants to ship a firmware update. They provide their technicians with USB keys, and cause a USB boot of the device, which runs the installer, and does the upgrade. | 12:23 |
| ssam2 | fair enough | 12:23 |
| persia | ssam2: Hrm. Good point. | 12:24 |
| pedroalvarez | that is what I was thinking when I accidentaly ran this upgrade | 12:24 |
| persia | Doesn't that cause issues with all deplpy-time scripts, actually? | 12:24 |
| ssam2 | we've said before that the current implementation of system-version-manager isn't the full story for people producing commercial devices with Baserock | 12:24 |
| ssam2 | persia: it means that you can't run binaries from the system at deploy time, yeah | 12:24 |
| ssam2 | persia: so when we need to do that we add a systemd unit at deploy time to run whatever we need on first boot | 12:25 |
| persia | To confirm my understanding, are configure extensions run at system assembly time, and write extensions at deploy time? | 12:25 |
| pedroalvarez | both run at deploy time | 12:26 |
| persia | So what runs at system-assembly time? system-integration scripts? | 12:27 |
| pedroalvarez | yes, and I believe that nothing else | 12:27 |
| persia | Hrm, so really, every deployment is a snowflake. | 12:28 |
| ssam2 | all the extensions are tracked in either morph.git or definitions.git, and they can only run commands off the host system | 12:29 |
| ssam2 | so provided the same host system is used, deployment should be totally reproducible | 12:29 |
| ssam2 | I've never proved that assumption myself | 12:29 |
| ssam2 | nor disproved it :) | 12:29 |
| persia | That assumption isn't safe for development teams. | 12:29 |
| persia | Or rather, most development teams :) | 12:30 |
| ssam2 | could you briefly expand on why? I'm not sure I understand. | 12:30 |
| persia | You and I want to have slightly different development environments, because we have different tooling preferences, so we don't have the same host system. | 12:31 |
| persia | I build and deploy a system, and then it fails miserably in some way that isn't code related. | 12:31 |
| persia | But that day I happen to be sick, so you need to deploy the replacement. | 12:31 |
| ssam2 | hmm, and deploy always happens in the local system | 12:32 |
| persia | Right. | 12:32 |
| persia | If "deploy" was just copying bits somewhere, it would matter less. | 12:32 |
| ssam2 | you could work around this by nominating a specific machine and saying "only deploy releases from here" | 12:32 |
| ssam2 | but I agree it's a bit ugly | 12:32 |
| persia | Even some transformations are fine, because they are standard transformations (e.g. tarball to raw) | 12:32 |
| persia | But as soon as we're executing any real code, we run into a reproducibility issue for teams of size larger than one. | 12:33 |
| persia | Yeah, I suppose one can nominate a "deployment environment" VM, but that doesn't smell that different than distbuild to me. | 12:35 |
| *** rdale [~quassel@15.Red-88-21-208.staticIP.rima-tde.net] has joined #baserock | 12:36 | |
| petefoth | pedroalvarez: would teh same trick work with the ssh-rsynch write extension? | 12:36 |
| ssam2 | I think if we want 100% reproducibility we have to run Morph in a completely controlled system | 12:37 |
| ssam2 | the hard part is making that not suck | 12:37 |
| pedroalvarez | petefoth: sorry, I'm not sure about what trick are you talking about :/ | 12:37 |
| ssam2 | for deploy, another option is to run all the configuration/provisioning commands *inside* the system after bringing it up | 12:38 |
| petefoth | pedroalvarez: let me rephrase? Currently ssh-rsynch.check raises an exception if the UPGRADE parameter is not set. If we removed that check, could we deploy an initial deployment? | 12:38 |
| ssam2 | but this adds fragility and makes some scenarios impossible | 12:38 |
| persia | ssam2: My thought is that we ought to be able to do a lot of it at system-assembly time, and cache the results. The only special bit ought be transferring the collection of bits to a final target form. | 12:38 |
| pedroalvarez | petefoth: no, ssh-rsync is exclusively to upgrade a running system | 12:38 |
| persia | Or do I misunderstand something in the chain? | 12:38 |
| *** madhu__ [~madhu@202.0.77.198] has quit [Quit: Leaving] | 12:38 | |
| ssam2 | persia: that's another angle, which I'd not thought of | 12:39 |
| petefoth | pedroalvarez: OK ta! | 12:39 |
| pedroalvarez | petefoth: np :) | 12:39 |
| ssam2 | persia: it requires that you have tools in your system available at assembly time needed to configure it, which you might want to strip out later, but we have that problem already with build tools | 12:39 |
| petefoth | supplementary question: if ssh-rsync.write can *only* be used for upgrades, why bother having a mandatory UPGRADE parameter which must evaluate to ‘true’? If I’m using this write extension then I *must* be doing an upgrade - why make me say so explicitly? | 12:42 |
| persia | ssam2: Hrm? Can't we build a staging area, add the system at some named point, and then fiddle with the system using tools from the staging area? | 12:42 |
| pedroalvarez | petefoth: some extensions can be used to upgrade, and some can't. For example, ssh-rsync can only be used to upgrade a running system, but rawdisk.write can also be used to upgrade a rawdisk image (and now also a disk), others like kvm or virtualbox can't be used to upgrade a system, that's why we added the upgrade flag, to specify when we want to do an upgrade an when we don't | 12:45 |
| ssam2 | persia: yes, I suppose we can. Good thinking. | 12:46 |
| persia | ssam2: I can't take credit. It is how I've seen images built before. | 12:46 |
| pedroalvarez | petefoth: I'll think about it anyway, maybe you are right | 12:46 |
| ssam2 | petefoth: you wouldn't set UPGRADE directly | 12:46 |
| ssam2 | petefoth: it's set when you run `morph upgrade` or `morph deploy --upgrade` | 12:46 |
| pedroalvarez | but the point is: why we need to check if the UPGRADE is set if the ssh-rsync exts only can be used to upgrade? | 12:47 |
| petefoth | ssam2: as I understand it you *could*. But … what pedroalvarez just said :) | 12:48 |
| ssam2 | when a user tries to run `morph upgrade` using kvm.write, the tool can advise them that kvm.write is only for initial deployments and they should look to ssh-rsync.write instead | 12:48 |
| ssam2 | being able to warn a user that tries an initial deployment using 'ssh-rsync.write' is perhaps less useful, but still better I think than what would happen if we didn't do that sanity-check | 12:48 |
| ssam2 | in both cases, without that check the user would probably get an error about the 'location' field being invalid | 12:49 |
| ssam2 | rather than their chosen write extension being the wrong one | 12:49 |
| * petefoth remains unconvinced, but will document what the code currently does :) | 12:50 | |
| petefoth | ssam2: is it actually *possible* for the user to set the UPGRADE parameter directly? If it is, then would a call to morph deploy with it set actually succeed, or does morph upgrade do some additional magic? | 12:53 |
| persia | Does running `morph upgrade` overwrite any user-provided UPGRADE value? Does running `morph deploy` without `--upgrade` also do this? If not, could they to save this confusion? | 12:53 |
| petefoth | So the documentation for DeployPlugin.upgrade says ‘See `morph help deploy` for documentation.” but the docstring for DeployPlugin.deploy doesn’t mention ‘upgrade’. I guess it will need to! | 13:02 |
| pedroalvarez | I think that `morph upgrade` calls `morph deploy --upgrade` | 13:03 |
| pedroalvarez | and I believe that the upgrade flag can also be set in the cluster morphology | 13:04 |
| pedroalvarez | various ways to do the same thing :) | 13:04 |
| petefoth | pedroalvarez: OK. I understand that, though the code indicates that ‘morph deply —upgrade’ is deprecated | 13:05 |
| pedroalvarez | oh, maybe | 13:06 |
| petefoth | pedroalvarez: that doesn’t really matter (to me, at the moment). What is not good is that the help for ‘morph upgrade’ directs the user to ‘morph help seply’ which doesn’t mention ‘upgrade’ | 13:07 |
| petefoth | s/seply/deploy/ | 13:07 |
| petefoth | I’ll create a new task to add information about upgrade to the help for ‘morph deploy’ | 13:08 |
| petefoth | This task - documenting the write extensions- will run and run :) | 13:08 |
| petefoth | It will shortky have 12 sub-tasks! | 13:12 |
| petefoth | pedroalvarez: actually, if ‘morph deploy —upgrade’ is deprecated, then the information about upgrade shoud go in the docstring for DeployPlugin.upgrade not DeployPlugin.deploy | 13:13 |
| petefoth | pedroalvarez: ignore me, I’m talking to myself now :) | 13:13 |
| ssam2 | petefoth: I wrote that 'see `morph deploy` help text basically to avoid maintaining two copies of the same thing | 14:01 |
| ssam2 | I hope you can find a better way | 14:01 |
| petefoth | ssam2: fair enough. I’; | 14:02 |
| ssam2 | r.e. manually setting UPGRADE, the user could do that, but I'm not sure why they'd want to | 14:02 |
| petefoth | llthink about it when I get to that task | 14:02 |
| petefoth | ssam2: agreed, but if they *can* do it, be sure someone *will* do it | 14:03 |
| straycat | ssam2, http://sprunge.us/bVTS does this seem okay to you? | 14:04 |
| * persia thinks morph should override the user if they do | 14:04 | |
| straycat | I've not added tested packages yet because I'm still testing. | 14:05 |
| straycat | /fixing | 14:05 |
| ssam2 | I think the TODO items need a lot more fleshing out with context | 14:05 |
| * straycat was expecting git show to take ranges, but ended up using cat | 14:05 | |
| ssam2 | if I come to look at this in 6 months I don't think 'abstract popen/log' will mean anything to me | 14:05 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 14:06 | |
| straycat | heh, yeah i guess so | 14:06 |
| straycat | i know what i mean :3 >.> | 14:06 |
| ssam2 | README looks good from a quick skim | 14:06 |
| petefoth | persia: In *all* cases where the user may specify UPGRADE? | 14:07 |
| persia | Yes. | 14:07 |
| persia | That it happens to be that class of variable that morph uses to determine if it is an upgrade is an implementation detail that ought be hidden from users. | 14:07 |
| * persia is somewhat tempted to suggest a parse-time error, but suspects the relevant code is too deeply abstracted to support that cleanly. | 14:08 | |
| petefoth | persia: will you submit a patch, or add something in http://wiki.baserock.org/stories-for-storyboard/ ? | 14:08 |
| persia | For overriding UPGRADE? | 14:09 |
| ssam2 | persia: I consider the existance of the UPGRADE flag an implementation detail | 14:09 |
| petefoth | persia: yes. Why not? How else do we document changes that we would like to see finding their way into Baserock? | 14:10 |
| ssam2 | persia: so code that prevents the user setting it manually seems like a good idea to me | 14:10 |
| persia | ssam2: Do we have a facility for that, or is it a maze of little twisty abstractions, all alike? | 14:11 |
| persia | petefoth: Sorry: just confirming between the override facility and the parse-time rejection facility. | 14:12 |
| petefoth | persia: np. Currently, at parse time we will a: reject a call to morph upgrade if the write extension does not support upgrade. b: reject a call to ‘morph upgrade —upgrade’ c: reject a call to deploy using ssh-rsync if the UPGRADE parameter / env variable isn’t set (I think) | 14:15 |
| straycat | ssam2, http://sprunge.us/AKGb ? | 14:15 |
| straycat | some of these TODOs may disappear soon, I hope. :) | 14:15 |
| persia | petefoth: Cool. What I think I want is to reject UPGRADE if it is set in all contexts at parse-time AND override it if it is set anyway. | 14:16 |
| ssam2 | persia: i'm not sure off hand, but the mechanisms at work are deliberately quite simple | 14:16 |
| persia | ssam2: OK. I'll ask for it then :) | 14:16 |
| persia | petefoth: Do you think that model will make it easy to (not) document UPGRADE? | 14:16 |
| petefoth | persia: I haven’t managed to parse your description yet :) | 14:17 |
| ssam2 | straycat: that's better for that one | 14:17 |
| ssam2 | I'm a bit confused about scheme x.y e.g. pip.find_deps should avoid using a '.' makes it more difficult to import extensions as modules.' too | 14:18 |
| ssam2 | 'import tool needs to know what's already in definitions and where it is to avoid importing stuff that we already have.' is covered in the main TODO | 14:18 |
| straycat | okay | 14:18 |
| straycat | the former: consider import pip.find_deps for use in a test suite | 14:19 |
| straycat | I'll add that explanation | 14:19 |
| ssam2 | ah, right | 14:20 |
| straycat | we get around this with imp at the moment, and out of all the TODOs, it's probably the lowest priority because fixing it doesn't improve functionality at all | 14:20 |
| straycat | i'll drop the second one | 14:20 |
| petefoth | What I think you mean is a: only allow ‘morph upgrade’ or ‘morph deploy’, not ‘morph deploy —upgrade. b: reject calls to ‘morph upgrade’ using extension that don’t support it. c: reject calls to morph deploy using ssh-rsynch which on allows upgrade, not initial deployment. At that point the onl use for UPGRADE is internal to the DeployPlugin class: if it is set before the call to morph deploy / upgrade / whatever, | 14:24 |
| petefoth | that’s an error too. | 14:24 |
| petefoth | persia: I’m not sure I’ve fully grasped what you are suggesting. | 14:25 |
| persia | petefoth: Almost, but not quite. | 14:25 |
| persia | Let me try again :) | 14:25 |
| persia | If a user adds UPGRADE to a cluster definition, morph should provide a parse error. | 14:25 |
| persia | If morph is running in upgrade mode (either `morph upgrade` or `morph deploy --upgrade`, morph should unconditionally set UPGRADE to True, regardless of any user-provided settting. | 14:26 |
| persia | If morph is running in deploy mode (`morph deploy` without "--upgrade"), morph should unconditionally set UPGRADE to False, regardless of any user-provided setting. | 14:26 |
| persia | /end conditionals | 14:27 |
| * SotK updates a VM in OpenStack and loses network :( | 14:30 | |
| SotK | I assume this is because of the systemd update | 14:30 |
| petefoth | persia: the fog is lifting :) That does make sense to me. In terms of documentation it should be doable too: the bulk of the upgrade documentation is in ‘morph help upgrade’. ‘morph help deploy’ mentions the ‘—upgrade option as an alternative way of calling ‘morph upgrade’ and refers to ‘morph help upgrade’. | 14:31 |
| petefoth | persia: I would only add, why not remove ‘morph deploy —upgrade’? we already say it’s deprecated: if the user wants to upgrade use ‘morph upgrade’ *not* morph deploy | 14:31 |
| persia | petefoth: In my mind, the use of UPGRADE is separate from the manner in which the user invokes upgrade. | 14:32 |
| persia | Aside from that, I think I agree with you. | 14:32 |
| petefoth | :) | 14:32 |
| pedroalvarez | SotK: yes, let me help you to fix it | 14:33 |
| pedroalvarez | SotK: you have to edit /etc/systemd/network/10-dhcp.network | 14:34 |
| pedroalvarez | and change en* by e* or eth0, or eth* | 14:34 |
| SotK | pedroalvarez: thanks :) | 14:35 |
| persia | Can we revert the systemd update, or land a patch including the changes to the configuration? | 14:35 |
| persia | Having it always broken seems wrong. | 14:35 |
| pedroalvarez | is not always, is only in openstack :( | 14:36 |
| persia | really? I wouldn't have thought openstack networking was that different from KVM networking. | 14:36 |
| persia | (from the POV of a VM) | 14:36 |
| petefoth | So, do I write the documentation on the basis of how the code *is*, and revisit it if/when your proposed change is implemented? Or do I document how persia *would* *like* the code to be? | 14:37 |
| pedroalvarez | persia: I have no clue about why this happens, but yes, I want a fix | 14:37 |
| persia | petefoth: You should probably write the docs for the code as it exists. I want lots of things, but it is sometimes months or years before people get around to implementing things I want. | 14:38 |
| straycat | It's often months or years before I get around to implementing the things I want. :( | 14:38 |
| persia | pedroalvarez: Ah, ugh. Unknown bugs are the worst. I thought it was just a matter of synchronising config and systemd version. | 14:39 |
| petefoth | persia: I will dump the relevant bits of this dicscussion into http://wiki.baserock.org/stories-for-storyboard/ so that it doesn’t get lost. Then I’ll get on with docs | 14:40 |
| persia | Don't fuss. I'm adding the story in ~5 minutes :) | 14:40 |
| pedroalvarez | persia: I'd say that the current configuration for systemd is not enough | 14:41 |
| pedroalvarez | or that we should do something that the network interface name is always called eth0 | 14:42 |
| persia | pedroalvarez: Does the config you suggested work for other deployment types? If so, should we just have that be the default? | 14:42 |
| persia | I don't want to always call the network device eth0 | 14:42 |
| petefoth | persia: OK - I’ll kleav it to you - sorry! | 14:42 |
| pedroalvarez | persia: why not? | 14:42 |
| persia | petefoth: No, thank you for offering. Sometimes I have too many things in my head to get to stuff. Today is a good day. :) | 14:42 |
| persia | pedroalvarez: Because I have lots of networking devices connected lots of ways, and I have experienced most of the bugs that the new system is intended to solve. | 14:43 |
| persia | Hacking the new system to have the bugs again strikes me as wrong. Better is to fix whatever is depending on eth0 to parse things properly, and use that. | 14:43 |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 244 seconds] | 14:46 | |
| *** elevenarms______ [~elevenarm@64.9.130.191] has quit [Remote host closed the connection] | 14:51 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:06 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 15:18 | |
| straycat | bah, python requirements are apparently case insensitive but the xmlrpclib calls aren't | 15:20 |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 256 seconds] | 15:23 | |
| pedroalvarez | I think I don't agree with richard_maw when he says that the installer.py should be installed by a chunk | 15:37 |
| pedroalvarez | I'd only agree if all the system have it | 15:37 |
| pedroalvarez | well, only the systems that have morphlib actually | 15:39 |
| pedroalvarez | maybe it could go in morph-utils | 15:39 |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 15:50 | |
| * straycat just noticed our /etc/network/interfaces is broken | 16:44 | |
| straycat | Since it's referring to eth0 | 16:44 |
| straycat | Or am I mistaken? I haven't really been following the recent changes to interface naming, but I now have ens3 instead of eth0 | 16:44 |
| straycat | And cleverly decided to take that interface down while sshd in >.> Then found ifup didn't work | 16:45 |
| genii | Dell has now a constant naming scheme for interfaces but it can be disabled at boot time with biosdevname=0 | 16:50 |
| persia | Can it be made to work sensibly *without* disabling it? | 16:52 |
| * persia has seen lots of discussion about how to disable systemd 217 features, but not so much about how to make it work, and worries a bit | 16:52 | |
| genii | persia: Probably, but i haven't delved much into their documentation about it | 16:55 |
| genii | I had the same issue on some Debian boxes, just disabled it since a lot of our scripts use the ethX scheme | 16:56 |
| persia | I think straycat identified the problem, being that /etc/network/interfaces would have needed to have been updated when systemd was upgraded. | 16:57 |
| persia | But I heard there was some new systemd thing that did networks, so maybe we don't want/need /etc/network/interfaces in most cases? | 16:57 |
| straycat | but then I'll have to learn new commands :( | 16:58 |
| persia | Good for you. Exercises the brain. :) | 16:58 |
| * straycat isn't too fond of change :( | 16:58 | |
| * persia hopes for automation, so that this can be a matter of forgetting the old commands, rather than learning new ones. | 16:58 | |
| persia | We could just revert the systemd upgrade. | 16:59 |
| straycat | Well if I want to manually disable a connection I'm always going to need to know something | 16:59 |
| robtaylor | /etc/network/interfaces systemd | 17:00 |
| robtaylor | http://lmgtfy.com/?q=%2Fetc%2Fnetwork%2Finterfaces+systemd | 17:00 |
| robtaylor | =) | 17:00 |
| * straycat doesn't appreciate that | 17:00 | |
| straycat | I'm quite busy, which is why I didn't google | 17:00 |
| jmacs | Are there any guidelines as to which bits of software should go in tools/ and which should have their own top-level stratum? | 17:01 |
| straycat | If I'm going to be mocked I'll avoid reporting issues like this one in future. | 17:01 |
| robtaylor | straycat: as much to you as emmet - really why discuss without checking the facts? | 17:01 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:02 | |
| robtaylor | straycat: but yes, according to my google, the anser is, that is no longer used and can be simply removed | 17:04 |
| robtaylor | straycat: and if you want to configure network interfaces do 'man systemd.network' | 17:04 |
| ssam2 | jmacs: no concrete rules | 17:06 |
| ssam2 | In general, I think if things have lots of dependencies that aren't needed by other things, they need to be in their own stratum | 17:06 |
| persia | jmacs: If you can imagine a sensible system that has foo, but not the rest of tools, or the rest of tools, but not foo, then it should be separate. | 17:06 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:07 | |
| jmacs | persia: That sounds sensible. | 17:07 |
| persia | jmacs: Don't get too excited looking for corner cases. In my mind, we have > 10,000 chunks, but only ~1000 strata. | 17:08 |
| *** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:10 | |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [] | 17:11 | |
| jmacs | Argh, BitKeeper. | 17:27 |
| robtaylor | what? where? | 17:30 |
| robtaylor | wfzxomgoneoneone | 17:30 |
| jmacs | ntp. | 17:30 |
| jmacs | I don't think the version in busybox is going to cut it for chef. | 17:30 |
| robtaylor | wow, that is complete wtf | 17:31 |
| jmacs | They do have regular source tarballs though | 17:32 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:32 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:43 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:54 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:57 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 18:00 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:35 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 19:35 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:35 | |
| jjardon | Hi, is there any reason to use different kernel versions for each architecture instead using the latest one? | 20:16 |
| persia | I think it is because folk like to test kernel changes, and can only usefully test one architecture at a time. | 20:20 |
| paulsher1ood | +1 for latest (tag release) kernel | 20:21 |
| persia | Err, if it boots. | 20:22 |
| * persia has seen tag release kernels that didn't boot with a given configuration, and needed config rework to be usable. | 20:23 | |
| paulsher1ood | agreed, assuming it boots | 20:23 |
| paulsher1ood | (and system tests (mason) pass) | 20:24 |
| paulsher1ood | config work needs redoing on network afaict | 20:24 |
| persia | That's from a systemd change, rather than a kernel change. | 20:26 |
| paulsher1ood | ironically straycat (who seems to have droppped off here, and i can't blame him) flagged that network config was broken just as i was failing to ssh to my vm over the atlantic, because network config is brojenb | 20:26 |
| persia | We need to not ship /etc/network/interfaces anymore, and not depend on having eth0 | 20:26 |
| paulsher1ood | agreed. but same rules apply :) | 20:26 |
| persia | Indeed. I'm really tempted to revert the systemd change until someone spends the time to figure out how to make the network do things correctly. | 20:27 |
| paulsher1ood | jjardon would be best bet for a solution, maybe? | 20:27 |
| persia | That said, I'm unlikely to actually do either of those right now, because I am currently only working in chroots. | 20:27 |
| paulsher1ood | how is that going? | 20:28 |
| persia | I have a working compatible-architecture chroot. I keep getting distracted from my attempts to get a native-architecture chroot with cross-bootstrap. | 20:30 |
| robtaylor | paulsher1ood: i think jjardon is pretty busy on other things at the moment | 20:30 |
| persia | We did manage to solve the build issues, so my compat-architecture chroot is now fully functional. | 20:30 |
| paulsher1ood | robtaylor: my point was, his change broke it... i hoped he might have some perspective on fixing it | 20:31 |
| robtaylor | paulsher1ood: I think the problem is knowing what the desired behaviour is in teh cases folks are hitting | 20:35 |
| * robtaylor has no idea what systems would be doing to require the existance of eth0, for example | 20:36 | |
| robtaylor | but its all really easy to fix if you do know - all described here http://www.freedesktop.org/software/systemd/man/systemd.network.html | 20:37 |
| persia | robtaylor: For starters, morph assumes it for nfsboot.configure, simple-network.configure, and virtualbox-ssh.write | 20:37 |
| persia | Which essentially means every system has the wrong network configuration, or no networking (as nearly all use simple-network.configure) | 20:38 |
| paulsher1ood | robtaylor: i don't know, so it's not easy for me. and the issue is that our default systems now seem to *assume* working eth0. which is not great if there isn't one. | 20:38 |
| * juergbi wishes linux network interfaces provided device nodes like everything else | 20:39 | |
| juergbi | and persistent names could simply be symlinks to ethN | 20:40 |
| paulsher1ood | s/the issue/one issue/ | 20:40 |
| * persia agrees with juergbi | 20:40 | |
| * paulsher1ood can't help fix this, so will shut up now | 20:41 | |
| robtaylor | juergbi: that would be good | 20:52 |
| robtaylor | persia: i was given to understand you just don't need simple-network now | 20:52 |
| persia | robtaylor: Is morph modified to not use it? | 20:53 |
| persia | I suspect you to be correct. I'm not convinced that we have done all the bits necessary for the transition. | 20:53 |
| persia | Hrm. No, that landed: the systems that have systemd all don't have simple-network, so there's something else not happening somewhere. | 20:57 |
| persia | Well, except that systems/devel-system-x86_64-generic.morph seems to still have simple-network for some reason (as opposed to the other cases that were removed), which may be affecting some folk. | 20:58 |
| * persia becomes increasingly confused at what seems a random set of systems that have/don't have simple-network, and goes back to other things | 21:00 | |
| Kinnison | I think you're trying to find a pattern in what increasingly seems to be an incomplete transition | 21:15 |
| Kinnison | I think jjardon needs to complete the transition he started when he insisted on migrating us from ifupdown to networkd | 21:16 |
| radiofree | well it wasn't just him, the patches were reviewed | 21:50 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:02 | |
| radiofree | why is a build-system image release 6GB big? | 22:04 |
| SotK | I assume to allow space for some upgrades to be done? | 22:05 |
| rjek | Size of image file used to construct the file system? | 22:05 |
| rjek | How big is it /actually/? (ie, allowing for sparse files) | 22:06 |
| SotK | It used to be about 2.5G (before we renamed old devel- to build-), so I would imagine around that | 22:07 |
| radiofree | it's 1.4G on the fs | 22:07 |
| rjek | There you go then :) | 22:07 |
| radiofree | no i mean in the vm, 1.4G is used | 22:07 |
| radiofree | 6GB for updates makes sense though... | 22:07 |
| radiofree | but can't you expand it manually? (then use btrfs filesystem resize max /)? | 22:08 |
| radiofree | i only say because it took ages to extract on this craptop | 22:08 |
| SotK | radiofree: you can indeed do that | 22:08 |
| rjek | man 1 truncate | 22:16 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 22:16 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 22:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:16 | |
| rjek | (to make the image larger) | 22:16 |
| rjek | You may then need to online-resize inside | 22:16 |
| radiofree | yeah i don't need it larger i just wanted to test it | 22:20 |
| radiofree | but 6GB is fine, if your hardware takes ages to extract that you're probably going to have a bad time with baserock anyway | 22:21 |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 250 seconds] | 22:59 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 23:24 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 23:26 | |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 258 seconds] | 23:31 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 23:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!