IRC logs for #baserock for Wednesday, 2014-12-03

*** elevenarms [~elevenarm@58.251.146.236] has joined #baserock00: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 #baserock08:11
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock08:19
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]08:19
De|ta_ is now known as De|ta08:54
*** elevenarms_ [~elevenarm@43.249.128.153] has joined #baserock08:55
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:04
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:08
*** elevenarms__ [~elevenarm@183.38.151.176] has joined #baserock09:15
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:16
*** elevenarms_ [~elevenarm@43.249.128.153] has quit [Ping timeout: 264 seconds]09:19
*** elevenarms___ [~elevenarm@43.249.128.217] has joined #baserock09:24
*** elevenarms__ [~elevenarm@183.38.151.176] has quit [Ping timeout: 252 seconds]09:24
petefothIs 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 #baserock09: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 #baserock09:31
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:32
SotKMorph definitely follows PEP8, and its test suite checks that it does (`./check --style`).09:34
SotKAlthough having said that it doesn't seem to run the pep8 style checker, rather a script of our own.09:35
petefothSotK: that’s alright then. I will add something to the ‘contributing’ wiki page09:35
petefothSotK: oh - your second post is sad. Why not use pep8? Is our script better?09:36
*** elevenarms_____ [~elevenarm@183.38.151.176] has joined #baserock09:37
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09: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
SotKpetefoth: 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 #baserock09:41
*** elevenarms_____ [~elevenarm@121.15.111.206] has quit [Ping timeout: 256 seconds]09:46
*** elevenarms_____ [~elevenarm@64.9.146.198] has joined #baserock09:47
petefothAny thoughts on this question from yesterday: 09:50
petefoth13: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 #baserock09:54
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:57
Mode #baserock +v ssam2 by ChanServ09:57
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:06
*** elevenarms______ [~elevenarm@64.9.146.206] has joined #baserock10: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
straycatpetefoth, it should fail10:17
straycatfrom what i can see it will fail10:17
straycateach check ext seems to check and fail if there's not an existing system10:17
petefothstraycat: thanks. I looked at some of the write extensions, but not the check extensions10:18
pedroalvareziirc  only 2 of them allow an upgrade10:22
pedroalvarezrawdisk and ssh-rsync10:22
petefothpedroalvarez: Indeed - from what I can see you use ssh-rsync to upgrade OpenStack, KVM and vbox-ssh VMS 10:25
pedroalvarezeven jetson boards! :)10:26
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:31
bashrcwhat kernel version is baserock on?10:38
ssam2the current version of the definitions format doesn't make it easy enough to answer that :)10:41
ssam2http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-x86_64-generic.morph10:41
ssam2that shows we're using this commit, in x86_64: http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/commit/?h=d67a0e110187abd560a1de63fa172894a52839d510:42
ssam2the 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 either10:43
robtaylorssam2: git describe is your friend10:43
ssam2I don't have linux.git checked out anywhere, and it's not available in the web interface10:43
ssam2but otherwise, it'd be handy10:44
bashrcdoes 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 reference10:44
robtaylori know for jetson bsp its 3.18-rc310:44
bashrcok10:44
robtaylorbashrc: yeah i've long thought a comment with a git-describe would be useful10:44
pedroalvarez3.15.0 for other architectures10:44
pedroalvarezbut can be upgraded or downgraded in around 20 minutes as paulsher1ood has proven  here: http://vimeo.com/11006577610:47
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:53
ssam2anyone remember what the problem is when `morph build` gives 'ValueError: need more than 0 values to unpack' ?10:53
ssam2I know I've seen it before but can't remember why10:53
SotKdid you do git clone rather than morph checkout or branch to get your definitions repo?10:54
ssam2no, but I think that's the reason I've seen it before10:55
ssam2however, the config in baserock/baserock/definitions/.git/config is present this time10:55
ssam2I 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 #baserock11:33
* pedroalvarez has accidentaly upgraded a baserock system with the combination of installer.py + rawdisk.write11:38
pedroalvarezthis is: running an installer system to upgrade your current baserock system instead of deploying a new one11:39
ssam2did it work?11:39
pedroalvarezyes11:39
pedroalvarezas expected :)11:39
pedroalvarezwell, it worked on the same way as a rawdisk upgrade11:44
pedroalvarezI'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 #baserock11:50
*** elevenarms______ [~elevenarm@121.15.111.206] has quit [Ping timeout: 250 seconds]11:55
*** elevenarms______ [~elevenarm@64.9.130.191] has joined #baserock11:55
persiaDid 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
persiaIf so, call it an upgrade.  If not, should this be supported?12:16
* persia is thinking about the possibility of sneakernet upgrades12:16
pedroalvarezIIRC what how I implemented system-version-manager, yes, that command will show multiple entries12:17
pedroalvarezthe main difference that I see between this upgrade and the normal one (using ssh-rsync) is that we don't merge /etc nor /var12:19
persiaThen why isn't it an "upgrade"?12:19
persiaAh.  We should probably detect that condition, and do so.12:19
persiaOr 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
pedroalvarezif the deployment (deployment to an stroage device usign rawdisk.write extension) is not an upgrade, it will overwrite everything12:21
ssam2I guess it's hard to run system-version-manager in this type of upgrade, because we may not be able to execute binaries12:22
ssam2actually 'system-version-manager deploy' only needs Python and shell so it might be possible12:22
persiassam2: Why not?12:22
ssam2but might not be worth doing12:22
ssam2persia: 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 image12:23
persiaA 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
ssam2fair enough12:23
persiassam2: Hrm.  Good point.12:24
pedroalvarezthat is what I was thinking when I accidentaly ran this upgrade12:24
persiaDoesn't that cause issues with all deplpy-time scripts, actually?12:24
ssam2we've said before that the current implementation of system-version-manager isn't the full story for people producing commercial devices with Baserock12:24
ssam2persia: it means that you can't run binaries from the system at deploy time, yeah12:24
ssam2persia: so when we need to do that we add a systemd unit at deploy time to run whatever we need on first boot12:25
persiaTo confirm my understanding, are configure extensions run at system assembly time, and write extensions at deploy time?12:25
pedroalvarezboth run at deploy time12:26
persiaSo what runs at system-assembly time?  system-integration scripts?12:27
pedroalvarezyes, and I believe that nothing else12:27
persiaHrm, so really, every deployment is a snowflake.12:28
ssam2all the extensions are tracked in either morph.git or definitions.git, and they can only run commands off the host system12:29
ssam2so provided the same host system is used, deployment should be totally reproducible12:29
ssam2I've never proved that assumption myself12:29
ssam2nor disproved it :)12:29
persiaThat assumption isn't safe for development teams.12:29
persiaOr rather, most development teams :)12:30
ssam2could you briefly expand on why? I'm not sure I understand.12:30
persiaYou 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
persiaI build and deploy a system, and then it fails miserably in some way that isn't code related.12:31
persiaBut that day I happen to be sick, so you need to deploy the replacement.12:31
ssam2hmm, and deploy always happens in the local system12:32
persiaRight.12:32
persiaIf "deploy" was just copying bits somewhere, it would matter less.12:32
ssam2you could work around this by nominating a specific machine and saying "only deploy releases from here"12:32
ssam2but I agree it's a bit ugly12:32
persiaEven some transformations are fine, because they are standard transformations (e.g. tarball to raw)12:32
persiaBut as soon as we're executing any real code, we run into a reproducibility issue for teams of size larger than one.12:33
persiaYeah, 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 #baserock12:36
petefothpedroalvarez: would teh same trick work with the ssh-rsynch write extension?12:36
ssam2I think if we want 100% reproducibility we have to run Morph in a completely controlled system12:37
ssam2the hard part is making that not suck12:37
pedroalvarezpetefoth: sorry, I'm not sure about what trick are you talking about :/12:37
ssam2for deploy, another option is to run all the configuration/provisioning commands *inside* the system after bringing it up12:38
petefothpedroalvarez: 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
ssam2but this adds fragility and makes some scenarios impossible12:38
persiassam2: 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
pedroalvarezpetefoth: no, ssh-rsync is exclusively  to upgrade a running system12:38
persiaOr do I misunderstand something in the chain?12:38
*** madhu__ [~madhu@202.0.77.198] has quit [Quit: Leaving]12:38
ssam2persia: that's another angle, which I'd not thought of12:39
petefothpedroalvarez: OK ta!12:39
pedroalvarezpetefoth: np :)12:39
ssam2persia: 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 tools12:39
petefothsupplementary 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
persiassam2: 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
pedroalvarezpetefoth: 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't12:45
ssam2persia: yes, I suppose we can. Good thinking.12:46
persiassam2: I can't take credit.  It is how I've seen images built before.12:46
pedroalvarezpetefoth: I'll think about it anyway, maybe you are right12:46
ssam2petefoth: you wouldn't set UPGRADE directly12:46
ssam2petefoth: it's set when you run `morph upgrade` or `morph deploy --upgrade`12:46
pedroalvarezbut 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
petefothssam2: as I understand it you *could*. But … what pedroalvarez just said :)12:48
ssam2when 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 instead12:48
ssam2being 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-check12:48
ssam2in both cases, without that check the user would probably get an error about the 'location' field being invalid12:49
ssam2rather than their chosen write extension being the wrong one12:49
* petefoth remains unconvinced, but will document what the code currently does :)12:50
petefothssam2: 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
persiaDoes 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
petefothSo 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
pedroalvarezI think that `morph upgrade` calls `morph deploy --upgrade`13:03
pedroalvarezand I believe that the upgrade flag can also be set in the cluster morphology13:04
pedroalvarezvarious ways to do the same thing :)13:04
petefothpedroalvarez: OK. I understand that, though the code indicates that ‘morph deply —upgrade’ is deprecated13:05
pedroalvarezoh, maybe13:06
petefothpedroalvarez: 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
petefoths/seply/deploy/13:07
petefothI’ll create a new task to add information about upgrade to the help for ‘morph deploy’13:08
petefothThis task - documenting the write extensions- will run and run :)13:08
petefothIt will shortky have 12 sub-tasks!13:12
petefothpedroalvarez: actually, if ‘morph deploy —upgrade’ is deprecated, then the information about upgrade shoud go in the docstring for DeployPlugin.upgrade not DeployPlugin.deploy13:13
petefothpedroalvarez: ignore me, I’m talking to myself now :)13:13
ssam2petefoth: I wrote that 'see `morph deploy` help text basically to avoid maintaining two copies of the same thing14:01
ssam2I hope you can find a better way14:01
petefothssam2: fair enough. I’;14:02
ssam2r.e. manually setting UPGRADE, the user could do that, but I'm not sure why they'd want to14:02
petefothllthink about it when I get to that task14:02
petefothssam2: agreed, but if they *can* do it, be sure someone *will* do it14:03
straycatssam2, http://sprunge.us/bVTS does this seem okay to you?14:04
* persia thinks morph should override the user if they do14:04
straycatI've not added tested packages yet because I'm still testing.14:05
straycat /fixing14:05
ssam2I think the TODO items need a lot more fleshing out with context14:05
* straycat was expecting git show to take ranges, but ended up using cat14:05
ssam2if I come to look at this in 6 months I don't think 'abstract popen/log' will mean anything to me14:05
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]14:06
straycatheh, yeah i guess so14:06
straycati know what i mean :3 >.>14:06
ssam2README looks good from a quick skim14:06
petefothpersia: In *all* cases where the user may specify UPGRADE?14:07
persiaYes.14:07
persiaThat 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
petefothpersia: will you submit a patch, or add something in http://wiki.baserock.org/stories-for-storyboard/ ?14:08
persiaFor overriding UPGRADE?14:09
ssam2persia: I consider the existance of the UPGRADE flag an implementation detail14:09
petefothpersia: yes. Why not? How else do we document changes that we would like to see finding their way into Baserock?14:10
ssam2persia: so code that prevents the user setting it manually seems like a good idea to me14:10
persiassam2: Do we have a facility for that, or is it a maze of little twisty abstractions, all alike?14:11
persiapetefoth: Sorry: just confirming between the override facility and the parse-time rejection facility.14:12
petefothpersia: 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
straycatssam2, http://sprunge.us/AKGb ?14:15
straycatsome of these TODOs may disappear soon, I hope. :)14:15
persiapetefoth: 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
ssam2persia: i'm not sure off hand, but the mechanisms at work are deliberately quite simple14:16
persiassam2: OK.  I'll ask for it then :)14:16
persiapetefoth: Do you think that model will make it easy to (not) document UPGRADE?14:16
petefothpersia: I haven’t managed to parse your description yet :)14:17
ssam2straycat: that's better for that one14:17
ssam2I'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.' too14: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 TODO14:18
straycatokay14:18
straycatthe former: consider import pip.find_deps for use in a test suite14:19
straycatI'll add that explanation14:19
ssam2ah, right14:20
straycatwe 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 all14:20
straycati'll drop the second one14:20
petefothWhat 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
petefoththat’s an error too. 14:24
petefothpersia: I’m not sure I’ve fully grasped what you are suggesting.14:25
persiapetefoth: Almost, but not quite.14:25
persiaLet me try again :)14:25
persiaIf a user adds UPGRADE to a cluster definition, morph should provide a parse error.14:25
persiaIf 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
persiaIf 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 conditionals14:27
* SotK updates a VM in OpenStack and loses network :(14:30
SotKI assume this is because of the systemd update14:30
petefothpersia: 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
petefothpersia: 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 deploy14:31
persiapetefoth: In my mind, the use of UPGRADE is separate from the manner in which the user invokes upgrade.14:32
persiaAside from that, I think I agree with you.14:32
petefoth:)14:32
pedroalvarezSotK: yes, let me help you to fix it14:33
pedroalvarezSotK: you have to edit /etc/systemd/network/10-dhcp.network14:34
pedroalvarezand change en* by e* or eth0, or eth* 14:34
SotKpedroalvarez: thanks :)14:35
persiaCan we revert the systemd update, or land a patch including the changes to the configuration?14:35
persiaHaving it always broken seems wrong.14:35
pedroalvarezis not always, is only in openstack :(14:36
persiareally?  I wouldn't have thought openstack networking was that different from KVM networking.14:36
persia(from the POV of a VM)14:36
petefothSo, 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
pedroalvarezpersia: I have no clue about why this happens, but yes, I want a fix14:37
persiapetefoth: 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
straycatIt's often months or years before I get around to implementing the things I want. :(14:38
persiapedroalvarez: Ah, ugh.  Unknown bugs are the worst.  I thought it was just a matter of synchronising config and systemd version.14:39
petefothpersia: 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 docs14:40
persiaDon't fuss.  I'm adding the story in ~5 minutes :)14:40
pedroalvarezpersia: I'd say that the current configuration for systemd is not enough14:41
pedroalvarezor that we should do something that the network interface name is always called eth014:42
persiapedroalvarez: Does the config you suggested work for other deployment types?  If so, should we just have that be the default?14:42
persiaI don't want to always call the network device eth014:42
petefothpersia: OK - I’ll kleav it to you - sorry!14:42
pedroalvarezpersia: why not?14:42
persiapetefoth: 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
persiapedroalvarez: 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
persiaHacking 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 #baserock15:06
*** vmeson [~quassel@128.224.252.2] has joined #baserock15:18
straycatbah, python requirements are apparently case insensitive but the xmlrpclib calls aren't15:20
*** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 256 seconds]15:23
pedroalvarezI think I don't agree with richard_maw when he says that the installer.py should be installed by a chunk15:37
pedroalvarezI'd only agree if all the system have it15:37
pedroalvarezwell, only the systems that have morphlib actually15:39
pedroalvarezmaybe it could go in morph-utils15:39
*** vmeson [~quassel@128.224.252.2] has joined #baserock15:50
* straycat just noticed our /etc/network/interfaces is broken16:44
straycatSince it's referring to eth016:44
straycatOr am I mistaken? I haven't really been following the recent changes to interface naming, but I now have ens3 instead of eth016:44
straycatAnd cleverly decided to take that interface down while sshd in >.> Then found ifup didn't work16:45
geniiDell has now a constant naming scheme for interfaces but it can be disabled at boot time with biosdevname=016:50
persiaCan 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 bit16:52
geniipersia: Probably, but i haven't delved much into their documentation about it16:55
geniiI had the same issue on some Debian boxes, just disabled it since a lot of our scripts use the ethX scheme16:56
persiaI think straycat identified the problem, being that /etc/network/interfaces would have needed to have been updated when systemd was upgraded.16:57
persiaBut 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
straycatbut then I'll have to learn new commands :(16:58
persiaGood 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
persiaWe could just revert the systemd upgrade.16:59
straycatWell if I want to manually disable a connection I'm always going to need to know something16:59
robtaylor/etc/network/interfaces systemd17:00
robtaylorhttp://lmgtfy.com/?q=%2Fetc%2Fnetwork%2Finterfaces+systemd17:00
robtaylor=)17:00
* straycat doesn't appreciate that17:00
straycatI'm quite busy, which is why I didn't google17:00
jmacsAre there any guidelines as to which bits of software should go in tools/ and which should have their own top-level stratum?17:01
straycatIf I'm going to be mocked I'll avoid reporting issues like this one in future.17:01
robtaylorstraycat: 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
robtaylorstraycat: but yes, according to my google, the anser is, that is no longer used and can be simply removed17:04
robtaylorstraycat: and if you want to configure network interfaces do 'man systemd.network'17:04
ssam2jmacs: no concrete rules17:06
ssam2In general, I think if things have lots of dependencies that aren't needed by other things, they need to be in their own stratum17:06
persiajmacs: 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
jmacspersia: That sounds sensible.17:07
persiajmacs: 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
jmacsArgh, BitKeeper.17:27
robtaylorwhat? where?17:30
robtaylorwfzxomgoneoneone17:30
jmacsntp.17:30
jmacsI don't think the version in busybox is going to cut it for chef.17:30
robtaylorwow, that is complete wtf17:31
jmacsThey do have regular source tarballs though17: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 #baserock19:35
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]19:35
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:35
jjardonHi, is there any reason to use different kernel versions for each architecture instead using the latest one?20:16
persiaI 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) kernel20:21
persiaErr, 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
paulsher1oodagreed, assuming it boots20:23
paulsher1ood(and system tests (mason) pass)20:24
paulsher1oodconfig work needs redoing on network afaict20:24
persiaThat's from a systemd change, rather than a kernel change.20:26
paulsher1oodironically 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 brojenb20:26
persiaWe need to not ship /etc/network/interfaces anymore, and not depend on having eth020:26
paulsher1oodagreed. but same rules apply :)20:26
persiaIndeed.  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
paulsher1oodjjardon would be best bet for a solution, maybe?20:27
persiaThat said, I'm unlikely to actually do either of those right now, because I am currently only working in chroots.20:27
paulsher1oodhow is that going?20:28
persiaI have a working compatible-architecture chroot.  I keep getting distracted from my attempts to get a native-architecture chroot with cross-bootstrap.20:30
robtaylorpaulsher1ood: i think jjardon is pretty busy on other things at the moment20:30
persiaWe did manage to solve the build issues, so my compat-architecture chroot is now fully functional.20:30
paulsher1oodrobtaylor: my point was, his change broke it... i hoped he might have some perspective on fixing it20:31
robtaylorpaulsher1ood: I think the problem is knowing what the desired behaviour is in teh cases folks are hitting20:35
* robtaylor has no idea what systems would be doing to require the existance of eth0, for example20:36
robtaylorbut its all really easy to fix if you do know - all described here http://www.freedesktop.org/software/systemd/man/systemd.network.html20:37
persiarobtaylor: For starters, morph assumes it for nfsboot.configure, simple-network.configure, and virtualbox-ssh.write20:37
persiaWhich essentially means every system has the wrong network configuration, or no networking (as nearly all use simple-network.configure)20:38
paulsher1oodrobtaylor: 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 else20:39
juergbiand persistent names could simply be symlinks to ethN20:40
paulsher1oods/the issue/one issue/20:40
* persia agrees with juergbi20:40
* paulsher1ood can't help fix this, so will shut up now20:41
robtaylorjuergbi: that would be good20:52
robtaylorpersia: i was given to understand you just don't need simple-network now20:52
persiarobtaylor: Is morph modified to not use it?20:53
persiaI suspect you to be correct.  I'm not convinced that we have done all the bits necessary for the transition.20:53
persiaHrm.  No, that landed: the systems that have systemd all don't have simple-network, so there's something else not happening somewhere.20:57
persiaWell, 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 things21:00
KinnisonI think you're trying to find a pattern in what increasingly seems to be an incomplete transition21:15
KinnisonI think jjardon needs to complete the transition he started when he insisted on migrating us from ifupdown to networkd21:16
radiofreewell it wasn't just him, the patches were reviewed21:50
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]22:02
radiofreewhy is a build-system image release 6GB big?22:04
SotKI assume to allow space for some upgrades to be done?22:05
rjekSize of image file used to construct the file system?22:05
rjekHow big is it /actually/? (ie, allowing for sparse files)22:06
SotKIt used to be about 2.5G (before we renamed old devel- to build-), so I would imagine around that22:07
radiofreeit's 1.4G on the fs22:07
rjekThere you go then :)22:07
radiofreeno i mean in the vm, 1.4G is used22:07
radiofree6GB for updates makes sense though...22:07
radiofreebut can't you expand it manually? (then use btrfs filesystem resize max /)?22:08
radiofreei only say because it took ages to extract on this craptop22:08
SotKradiofree: you can indeed do that22:08
rjekman 1 truncate22:16
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock22:16
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]22:16
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock22:16
rjek(to make the image larger)22:16
rjekYou may then need to online-resize inside22:16
radiofreeyeah i don't need it larger i just wanted to test it22:20
radiofreebut 6GB is fine, if your hardware takes ages to extract that you're probably going to have a bad time with baserock anyway22: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 #baserock23:26
*** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 258 seconds]23:31
*** vmeson [~quassel@128.224.252.2] has joined #baserock23:56
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]23:56

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!