*** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 264 seconds] | 00:00 | |
*** vmeson [~quassel@128.224.252.2] has joined #baserock | 00:04 | |
*** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 245 seconds] | 00:16 | |
*** rdale [~quassel@15.Red-88-21-208.staticIP.rima-tde.net] has quit [Ping timeout: 252 seconds] | 01:32 | |
*** rdale [~quassel@192.Red-79-144-57.dynamicIP.rima-tde.net] has joined #baserock | 01:33 | |
jjardon | Kinnison: insist? I only sent patches that didn't brake any system in current definitions and were reviewed and accepted | 02:56 |
---|---|---|
jjardon | I asked for a system that its currently broken with thr new systemd so I can test in case I have some time: nothing is there yet | 02:57 |
jjardon | I asked (2 times) for feedback to adopt how coreos configure the network, so we do not need to parse any custom configuration in a script: no reply | 02:59 |
jjardon | Also, i can not read all the conversations in this channel,So if someone can write an email with the current issues he has with the network | 03:01 |
jjardon | I think it would be the best taking in account baserock doesn't have infrastructure to send bug reports yet | 03:03 |
*** petefoth1 [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 05:02 | |
*** petefoth2 [~petefothe@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 258 seconds] | 05:04 | |
*** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 258 seconds] | 05:11 | |
*** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has joined #baserock | 05:11 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:39 | |
radiofree | so if you use net.ifname=0 and a change the systemd network config to match on et* everything is back to normal | 07:56 |
radiofree | so, for systems that need eth0, add net.ifname=0 and adjust your /etc/systemd/network/*.network unit accordingly | 07:57 |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:06 | |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:53 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:56 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 08:59 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:59 | |
*** doffm [~mdoff@23.226.235.108] has quit [Ping timeout: 272 seconds] | 09:22 | |
*** doffm [~mdoff@23.226.235.108] has joined #baserock | 09:23 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:29 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 09:49 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:50 | |
Mode #baserock +v ssam2 by ChanServ | 09:50 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:52 | |
persia | radiofree: Shouldn't we fix it so that none of the systems with systemd need eth0? I got lost trying to sort out which systems were which, but I don't think trying to cause legacy behaviour is the ideal solution. | 10:13 |
jmacs | We've come across a lot of software this week that relies on eth0. | 10:14 |
persia | Yes, but it has to be patched anyway. Personally, I usually find most development teams happy to receive compatibility patches when their dependencies change in incompatible ways. | 10:15 |
* persia has seen one project go from 6 years dormant to active development again as a result of such a patch. | 10:16 | |
persia | That said, I do agree that it is annoying for those of us experiencing the pain, but just think about how much everyone else in the world will appreciate the work of making the problems go away :) | 10:16 |
radiofree | persia: that would be the idea situation yes | 10:24 |
radiofree | s/idea/ideal | 10:24 |
* persia is an optimist :) | 10:24 | |
radiofree | at least, for now, you can use net.ifname=0 | 10:24 |
paulsher1ood | radiofree: where would that patch go? | 10:28 |
pedroalvarez | paulsher1ood: sounds like a kernel arg | 10:29 |
persia | It's two things: 1) kernel arg (in clusters), and 2) adjustments to the systemd network unit (I don't know what provides this) | 10:30 |
pedroalvarez | 2) networkd conf provided by systemd chunk | 10:30 |
persia | RIght then, so changes to clusters and systemd chunk. | 10:31 |
radiofree | kernel arg | 10:32 |
pedroalvarez | the thing is that I like the idea of persistent network device names, but sounds like now they are unpredictable | 10:32 |
radiofree | ._o | 10:33 |
persia | pedroalvarez: The aren't: they are very predictable. The problem is that the predictability depends on the environment of the system, so that we need to be cleverer about generalising "the first network adaptor" for arbitrary system constructions. | 10:33 |
radiofree | the whole point of them is that they are predictable pedroalvarez | 10:34 |
radiofree | for example, if you had two wlan devices using the old convention, it's entirely possible for them to change between wlan0 and wlan1 | 10:35 |
radiofree | which means your lovingly handcraft iptables rules won't work | 10:35 |
pedroalvarez | I understand that, that's the reason why I like it | 10:35 |
pedroalvarez | as persia said, the names now depend on the environment of the system. From my point of view when configuring, you don't really know what name is going to have the ethernet device | 10:37 |
persia | radiofree: I have hardware where wireless ends up ethN, with N incrementing on each reboot. | 10:37 |
radiofree | pedroalvarez: the current setup works, ethernet devices are en* | 10:38 |
persia | pedroalvarez: That is also true with eth*: people just pretend it isn't. | 10:38 |
pedroalvarez | it was easier to pretend, at leaset | 10:38 |
pedroalvarez | least* | 10:38 |
radiofree | pedroalvarez: so the quickest solution is, when you have your systems that absolutely need it to be eth0, use net.ifname=0, and update the configuration script to write the correct systemd unit | 10:39 |
pedroalvarez | now if I deploy to openstack, eth0, to kvm ens3, to baremetal...? | 10:39 |
radiofree | i don't think using language like "x insisted on this" is going to help matters much | 10:40 |
persia | pedroalvarez: That you are getting "eth0" from OpenStack indicates something odd is happening. It would be interesting to know how that emerged from the policy. | 10:40 |
radiofree | unless insisted on is part of the nomenclature of baserock for a patch merge.... "james insisted on their being an armv7 hard float rootfs adding to the release" | 10:40 |
persia | radiofree: I think "insisted" is one of the rhetorical tricks that it is hard to remove from one's communication patterns, and is best ignored, or understood to be an expression of the writer's frustration. | 10:44 |
persia | Personally, I think out limited test infrastructure is to blame for the current problems, rather than either the upstream code, the submitter of the definitions patch (who did spend some time trying to sort things, and has promised a follow-up patch for some more fixups), or the reviewers (all of whom identified some issues that needed to be resolved for the new order, yet advocated merge anyway). | 10:46 |
petefoth | Current text of http://wiki.baserock.org/guides/upgrade-trove/ says to use the command ‘morph deploy --upgrade trove.baserock.org-upgrade.morph gbo.VERSION_LABEL=2014-05-29’. Can i just replace ‘deploy —upgrade’ with ‘upgrade’ in that command, or is the incantation different in orher ways? | 10:58 |
* radiofree wasn't aware there was an upgrade command | 10:59 | |
petefoth | sorry that shoudl be ‘morph deploy....' | 10:59 |
ssam2 | petefoth: yes, please replace with `morph upgrade` | 11:01 |
ssam2 | there's no difference in functionality | 11:01 |
petefoth | ssam2: just double checking - the rest of that command loine is unchanged? | 11:01 |
ssam2 | petefoth: yes | 11:01 |
radiofree | morph upgrade is "morph deploy --upgrade" then? | 11:01 |
ssam2 | radiofree: yes | 11:01 |
ssam2 | at the timewe introduced 'morph deploy --upgrade', some people expressed that they'd prefer it to be 'morph upgrade', and I later added it | 11:01 |
petefoth | radiofree: and morph deploy —upgrade is now deprecated | 11:02 |
radiofree | does your mac insist on changing things to unicode petefoth? :) | 11:03 |
petefoth | radiofree: not the Mac, it’s the Colloquy irc client - I’ll try and find the setting to turn that off | 11:03 |
* petefoth discovers Colloquy’s ‘Default encoding’ parameter, and restarts the app | 11:07 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 11:07 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:07 | |
* petefoth discovers that changing Colloquy’s ‘Default encoding’ parameter to ASCII doesn’t stop it converting various characters to unicode :( | 11:11 | |
persia | petefoth: You want to set the character set back to UTF-8, but adjust the input filter. Unfortuantely it has been so many years since I used Colloquy that I can't remember the menu sequence. | 11:12 |
*** locallycompact [~lc@8.108.125.91.dyn.plus.net] has joined #baserock | 11:17 | |
richard_maw | pedroalvarez: you said something about installer.py yesterday? | 11:24 |
* richard_maw is skimming backscroll | 11:24 | |
pedroalvarez | yup | 11:25 |
pedroalvarez | regarding your suggestion about puting it into a chunk | 11:25 |
richard_maw | why do you want it in all systems? | 11:26 |
petefoth | persia: thanks for the tip,but I can’t find any reference to input filter in the preferences or the help. I’lllive with it for now | 11:27 |
pedroalvarez | richard_maw: I didn't like the idea of creating a chunk for it. But I ended up thinking that it could be a good idea but if the installer is in the systems always, so we don't have to create extra systems to build an installer system | 11:28 |
* petefoth discovers the Keyboard | Text | 'USe smart quotes and dashes' setting in System Preferences, and turns it off :) | 11:29 | |
petefoth | ---- '' " :) | 11:29 |
persia | petefoth: That would be it :) | 11:29 |
richard_maw | I'd argue that this is why we should be attempting to reduce the amount of overhead in defining a system, but I can understand wanting to avoid adding more systems. | 11:29 |
petefoth | radiofree: it used to, now it doesn't :) | 11:30 |
persia | I like the idea of the installer being a system, because it means I can define a cluster with or without the installer, for the same payload. | 11:30 |
persia | Although on the other hand, if the installer could be part of a write extension, that makes it even easier (albeit with some maintenance cost) | 11:31 |
richard_maw | pedroalvarez: if we can come up with at least 1 use-case where a system not involved in pxeboot imaging would find it useful, then I wouldn't mind doing it that way. | 11:31 |
persia | A system has no network, and is installed by a technician booting from USB. | 11:32 |
persia | A system has slow/expensive network, and is upgraded by attaching USB at a service station every three months | 11:32 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 11:34 | |
richard_maw | the issue with having another system defined is that when deps change it's another defined system that needs to be corrected (which was one of the reasons for the runtime-depends patch) | 11:34 |
pedroalvarez | but also, if I define another system for this, then it will be smaller | 11:36 |
pedroalvarez | build-essential, core morph-uitls and bsp | 11:36 |
richard_maw | yep | 11:36 |
pedroalvarez | I'll go with dfining a different system, since the only use case for the installer script is to create installer systems (pxboot, usb, iso...) | 11:38 |
persia | Can we do ISO? I didn't think we had the necessary EL_TORITO magic | 11:41 |
richard_maw | not yet | 11:41 |
pedroalvarez | hehe, el torito | 11:41 |
rjek | ISO install would be nice | 11:41 |
persia | Heh. Thank you for the correction. | 11:41 |
persia | rjek: Preferable to USB, or equivalent, to you? | 11:42 |
rjek | I think it's a pretty well-understood problem to make an ISO image that can also be written to a USB stick. Debian have lots of command line tools for doing it. | 11:42 |
rjek | persia: It's often easier to boot a "CD" in virtual machines than a USB stick image, IME | 11:42 |
persia | rjek: I suppose, although if I'm dealing with a VM, wouldn't I just use the virtualbox, libvirt, kvm, or openstack write extensions? | 11:43 |
*** locallycompact [~lc@8.108.125.91.dyn.plus.net] has quit [Read error: Connection reset by peer] | 11:43 | |
rjek | How do you do that with the image file you just downloaded from baserock.org to get started? | 11:44 |
rjek | What if your dev environment is VMware, or Parellels? | 11:44 |
rjek | (Or, terror it be, Microsoft VirtualPC) | 11:45 |
persia | If you're downloading, it's a RAW image, so works for both of those. I'm not sure why I'd want to wrap the image in an "installer": that's just extra cycles to copy data. | 11:45 |
* persia doesn't know if VirtualPC supports RAW, but expects it does. | 11:45 | |
rjek | Download's probably smaller and more flexible :) | 11:45 |
persia | Not smaller, given the way the installer is implemented. | 11:45 |
persia | And not any more flexible, as it just copies the image to the target. | 11:45 |
rjek | Flexible, one hopes, as you get to choose file system and partition layout | 11:46 |
persia | A different installer may have the properties you mention, but install-time modification goes against the Baserock model, as it encourages snowflakes. | 11:46 |
rjek | developer's machines, where one might use an installer, are snowflakes. | 11:46 |
persia | rjek: For that, you want to define a cluster with the described properties. | 11:46 |
persia | rjek: The primary expected use case for the installer is a large room full of racks full of servers, not developer machines. | 11:47 |
persia | For a dev VM, the dev manages their own cluster, with their custom system definition, rebased frequently, and runs upgrade. | 11:47 |
rjek | Sounds like a job for Symantec's multicast IP Ghost product! | 11:47 |
persia | First time install, the default image is fine. | 11:47 |
persia | rjek: If someone wanted that, they could write a write extension. As far as I know, current efforts are to support OpenStack Ironic and IPMI-based installs. | 11:48 |
rjek | We really shoudn't be enabling IPMI fanatics. | 11:48 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:48 | |
persia | And the USB install thing is a free bonus side effect, which makes me happy, but doesn't seem to be the main thrust of development. | 11:48 |
persia | I refuse to say we should not do anything that fails to break other things. Flexibility is good. | 11:49 |
persia | If the IPMI fanatics happen to want to contribute to Baserock, that is a win for Baserock. | 11:49 |
persia | If the code bitrots, then there wasn't sufficient interest, so we can remove it later. | 11:50 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 11:55 | |
DavePage | Is there a difference between IPMI-based installs and PXE-based installs? I thought IPMI was used to tell a server to PXE boot. | 11:56 |
rjek | DavePage: IPMI has hideous extensions to let you "mount" a "CD" image over the network to boot from and things. | 11:56 |
DavePage | rjek: Ooh shiny | 11:56 |
persia | DavePage: As I understand the code, I think IPMI is used to cause a PXE boot of an image containing an installer, but I may not have the right model | 11:56 |
rjek | This is for people who hate standards. | 11:56 |
DavePage | Well, means you don't need a PXE server :) | 11:57 |
persia | Code landed recently to launch a PXE server in one's dev environment at the moment one needed one. | 11:57 |
rjek | (PXE being an open standard that consists of DHCP and then TFTP to fetch a payload, PXE providing a BIOS extension API for networking) | 11:57 |
rjek | There's no such thing as a PXE server :) | 11:57 |
persia | Doesn't help with really complicated networks, but handles the simple case, and there is probably already a TFTP server in the complex case. | 11:58 |
rjek | PXE is an API run on the machine to provide networking access to real-mode code | 11:58 |
persia | rjek: Fine. It launches a DHCP server and a TFTP server. | 11:58 |
persia | which combination I intend to conflate in the future by calling it a "PXE server" | 11:58 |
rjek | For Linux, you just TFTP load pxelinux, which uses the PXE API to fetch a config file that describes what kernel and initrd to fetch | 11:58 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:59 | |
*** locallycompact [~lc@8.108.125.91.dyn.plus.net] has joined #baserock | 11:59 | |
rjek | I think pxelinux lets you fetch via HTTP these days too | 11:59 |
rjek | persia: We used to just call them netboot servers, given since the dawn of time it's always been BOOTP/DHCP and TFTP :) | 11:59 |
persia | Perhaps. the code I saw doesn't do it that way. You can look at the relevant commits if you want real information, rather than excerpts from my faulty memory. | 12:00 |
persia | rjek: Yep. But "netboot server" sounds old-school, and "PXE server" sounds new and cool. Kinda like how SGML was unacceptable as a data transmission format, and XML was lauded as the best thing since sliced bread. | 12:00 |
rjek | pxelinux tries to fetch several files, based on MAC address prefixes, and then finally a default one | 12:01 |
rjek | "old school" == "reliable and well-understood" ;-) | 12:01 |
persia | If only most flacks agreed with you. It would make my life easier :) | 12:02 |
rjek | "new school" reminds me of the "new math", wonderfully satirised by Tom Lehrer. | 12:02 |
rjek | "You should do it this way, because the approach works in bases you'll never use!" | 12:02 |
* persia decides not to populate the irc log more, and goes off to deride things somewhere else | 12:04 | |
bashrc | in morph files for the linux kernel do you only need to specify a commit without the branch name? | 12:26 |
bashrc | also what does "unpetrify-ref" mean? | 12:27 |
radiofree | it tells you what the branch the ref exists in | 12:32 |
radiofree | or it might not | 12:32 |
radiofree | you can have a branch name/tag as the ref though | 12:33 |
bashrc | ok. Wouldn't that field be better described as "branch"? | 12:33 |
franred | jmac, regarding to your lorry, could https://github.com/abh/ntppool the source code repository that they use for making the tarball? | 13:13 |
franred | jmacs, ^^ | 13:14 |
jmacs | franred: Oh, I didn't realise that existed | 13:14 |
ssam2 | bashrc: yes, and I think we'll be changing the format of definitions soon to avoid the outdated 'unpetrify-ref' field | 13:14 |
jmacs | franred: It's not the same as the NTP tarballs though - what's the difference between ntp and ntppool? | 13:15 |
franred | jmacs, I got both from this page: http://www.ntp.org/ [tarball] http://support.ntp.org/bin/view/Main/SoftwareDownloads [repo] http://www.pool.ntp.org/en/ | 13:17 |
franred | maybe they are different projects | 13:18 |
franred | jmacs, I think the repo is here: http://support.ntp.org/bin/view/Main/SoftwareDevelopment | 13:20 |
jmacs | franred: Indeed it is - but it's BitKeeper | 13:20 |
franred | :( | 13:20 |
petefoth | Are there any restrictions on the VERSION_LABEL parameter for morph help deploy? Are spaces allowed? | 13:20 |
richard_maw | petefoth: morph won't complain, but system-version-manager list may be ambiguous to parse | 13:21 |
richard_maw | so cycle.sh may have problems, since it's currently the only thing that parses the output of svm list | 13:21 |
petefoth | so maybe we should recommend no spaces | 13:22 |
petefoth | ? | 13:22 |
richard_maw | we definitely need to ban / characters in it | 13:23 |
richard_maw | and \0, as you could embed that in the yaml | 13:23 |
richard_maw | hm no | 13:23 |
franred | jmacs, sorry for the noise, I've given you a +1 to merge the lorry | 13:23 |
richard_maw | actually \0 would get truncated, since it goes in the environment | 13:23 |
jmacs | franred: Cool, cheers. | 13:23 |
ssam2 | petefoth: I'd recommend just using alphanumeric characters and - | 13:23 |
ssam2 | if we advise users of this and they use funny characters, they get to keep the pieces | 13:24 |
richard_maw | as for whitespace, I'd prefer that we added a machine parsable output option to system-version-manager and made cycle.sh use that instead | 13:24 |
pedroalvarez | I like also "." | 13:24 |
richard_maw | pedroalvarez: good point, "." and ".." aren't possible | 13:24 |
petefoth | ssam2: can I use that phrase in the documnentation ? | 13:24 |
richard_maw | unless we encode the version labels in the write extension | 13:25 |
ssam2 | I think so :) | 13:25 |
petefoth | alpha-numerics and <hyphen> characters only shall be recommended! | 13:25 |
richard_maw | yep, since people write shell scripts and shell does the wrong thing by default | 13:26 |
* petefoth constrains himself to "should contain only alpha-numeric characters and the '-' (hyphen) character" | 13:27 | |
*** thecorconian [~jte@75-27-44-31.lightspeed.orpkil.sbcglobal.net] has joined #baserock | 13:43 | |
*** thecorconian [~jte@75-27-44-31.lightspeed.orpkil.sbcglobal.net] has quit [] | 13:44 | |
*** thecorconian [~jte@75-27-44-31.lightspeed.orpkil.sbcglobal.net] has joined #baserock | 13:45 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 13:48 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:49 | |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 13:49 | |
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:49 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:49 | |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 13:49 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 13:49 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:49 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:49 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:49 | |
*** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:49 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
Mode #baserock +v ssam2 by ChanServ | 13:50 | |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
*** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
bashrc_ | ssam2: to increase the chances of community engagement it may be a good idea to avoid too much esoteric terminology (like "unpetrify") | 13:53 |
bashrc_ is now known as bashrc | 13:53 | |
ssam2 | bashrc_: I think we're all on board the 'avoid inventing new terms' boat now :) | 13:54 |
ssam2 | although I don't think this will solve all our problems, as overloading existing terms can also create confusion | 13:55 |
ssam2 | but we will be moving to remove stuff like 'unpetrify' | 13:55 |
bashrc | true, although I'm not suggesting that the terminology always needs to be completely bland and generic | 13:55 |
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:00 | |
ssam2 | things were looking really good for actually finishing off importing Rails today | 14:01 |
ssam2 | until ... | 14:01 |
ssam2 | UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 15-16: truncated \uXXXX escape | 14:01 |
ssam2 | oh, actually I know the problemn | 14:02 |
ssam2 | for an unrelated reason my 'PS1' environment variable has colour escapes codes in it now | 14:03 |
DavePage | Unicodedecodedecodecodecodecode | 14:03 |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:03 | |
ssam2 | and seems nobody else using Baserock has ever done that. 'morph deploy' breaks in such a case! | 14:04 |
ssam2 | actually, it's not the colour codes but the sequence '\u' that breaks it. | 14:09 |
ssam2 | json.dumps('\u', encoding='unicode-escape') causes the same problem | 14:09 |
petefoth | can rawdisk.write be used to upgrade a vm that was deployed using a different write extension, such as kvm, vbox-ssh and/or openstack? | 14:09 |
ssam2 | I have no idea how to fix this to be honest. | 14:09 |
pedroalvarez | so, I'd like to create a repo to put the installer script. I think that baserock/baserock/installer-scripts would be ok to match with the name of the initramfs-scripts one | 14:09 |
ssam2 | seems OK | 14:10 |
ssam2 | I worry that we have too many repos, and wonder if it might be nicer to have a 'system-tools' repo that included the installer, plus tbdiff and system-version-manager | 14:10 |
ssam2 | but that's creating extra work for you | 14:11 |
*** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 14:11 | |
pedroalvarez | but you are probably right | 14:11 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:11 | |
petefoth | Now it's a bit quieter, I'll try again :) can rawdisk.write be used to upgrade a vm that was deployed using a different write extension, such as kvm, vbox-ssh and/or openstack? | 14:19 |
pedroalvarez | I woudn't say that is possible because then we will have to document it and it doesn't sound easy to do | 14:20 |
petefoth | pedroalvarez: OK. So I'll say it can be used to upgrade a system that was deployed as a raw disk image | 14:21 |
pedroalvarez | It can be used to upgrade raw disk images | 14:22 |
petefoth | pedroalvarez: is that different to what I just wrote? | 14:22 |
petefoth | if the raw disk image we are upgradng is perhaps not a Baserock system but a disk that is *used* by a system? | 14:23 |
* pedroalvarez is not being fast at writing today | 14:24 | |
pedroalvarez | I guess that "to upgrade a system that was deployed as a raw disk image" can cause confusion. | 14:24 |
pedroalvarez | you can deploy a system as a rawdisk, and then upload it to Openstack, or run it on virt-manager | 14:25 |
pedroalvarez | they were deployed as a rawdisk image, but rawdisk.write extension only allows you to upgrade a rawdisk image | 14:26 |
pedroalvarez | arg.. english.. | 14:26 |
pedroalvarez | petefoth: you know what I mean? | 14:26 |
petefoth | pedroalvarez: so we can upgrade the ram disk image then deploy that upgraded raw disk image (using morph deploy) to OpenStack or libvirt or vbox? | 14:28 |
* petefoth is beginning to get the picture | 14:28 | |
pedroalvarez | no, I think I screwed up your picture | 14:28 |
pedroalvarez | sorry :( | 14:28 |
petefoth | can we talk in 302 meeting room? | 14:29 |
petefoth | it's probably quicker than typing | 14:29 |
pedroalvarez | I'll try to explain this to you later, I'm busy at the moment :) | 14:29 |
petefoth | pedroalvarez: OK give me ahout when t's convenient | 14:30 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:07 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 15:27 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 15:27 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:27 | |
radiofree | is there an install equivalent of cp -r * $DESTDIR/foo/ | 16:02 |
richard_maw | not as far as I know | 16:03 |
radiofree | ok, i'll explain in the commit message why i used cp then | 16:03 |
richard_maw | you might be able to run `find -mindepth 1 -depth -type f -exec install -D {} "$DESTDIR/foo/" ';'`, but cp -r is more easily comprehensible | 16:07 |
DavePage | Should it be cp -ar ? | 16:08 |
radiofree | i don't think i've ever used -a... | 16:10 |
richard_maw | DavePage: -a implies -r | 16:13 |
richard_maw | -a includes permissions | 16:13 |
DavePage | richard_maw: I see that now :) | 16:13 |
richard_maw | this has somehow reminded me of how bad rsync's command-line is sometimes. If you want to copy a file from one location to another, and the filename may have spaces or glob characters in, you need to both (-s, --protect-args) and to glob escape the target path! | 16:15 |
richard_maw | --protect-args stops it interpreting the spaces as argument separators, ~ home substitution and $variable_substitution | 16:16 |
richard_maw | but it still globs! | 16:16 |
richard_maw | it's stuff like this which makes me wonder whether posix specifying the set of characters allowed in a file name would actually be a good idea | 16:18 |
*** thecorconian [~jte@75-27-44-31.lightspeed.orpkil.sbcglobal.net] has quit [] | 16:24 | |
*** icanicant [~klawson@195.88.236.129] has quit [Remote host closed the connection] | 16:26 | |
ssam2 | jmac: did you ever fix the Gem certificates error you mentioned the other day? | 16:26 |
ssam2 | Gem::RemoteFetcher::FetchError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/gems/rake-10.4.2.gem) | 16:26 |
ssam2 | oh, update-ca-certificates | 16:27 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 244 seconds] | 16:54 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:56 | |
ssam2 | turns out the example I chose for the import tool tutorial is a crap example and the tool doesn't work that well for Rails | 16:57 |
*** sam__ [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:57 | |
rdale | what do you think is the problem with rails? | 16:57 |
ssam2 | rails itself imports fine, but to actually use it you need a fair few extra Gems which are considered optional dependencies | 17:00 |
ssam2 | (well, it doesn't import fine, I had to spend a whole section of the tutorial on how to fix up the corner cases, but it's not too bad) | 17:00 |
rdale | but you can get them from the Gemfile.lock file? | 17:00 |
ssam2 | at the moment the tool reads from the .gemspec file | 17:00 |
ssam2 | if you create a project with 'rails new foo' then you get a Gemfile, but not a .gemspec | 17:01 |
ssam2 | reading the Gemfile directly isn't a good idea in most cases because it lists a lot of things the developer finds handy during development, rather than essential runtime deps | 17:01 |
rdale | ah i see | 17:01 |
ssam2 | but here's a case where choosing that approach has come back to bite me | 17:01 |
ssam2 | at the last minute, as these things do | 17:02 |
rdale | i wouldn't be too bothered about getting extra gems that were only needed for development as long as it was automated | 17:04 |
ssam2 | The problem I had was that this often resulted in dependency loops | 17:06 |
ssam2 | the right answer is probably: read the Gemfile for the goal project (the thing actually being imported) and read the .gemspec file for everything else | 17:06 |
* ssam2 adds that to the TODO.rubygems file :( | 17:06 | |
rdale | i'm getting quite a lot of stuff when i run the import tool on each item individually that is in the Gemfile.lock file | 17:10 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:12 | |
ssam2 | rdale: it reads all the dependencies from the .gemspec file | 17:13 |
ssam2 | usually the Gemfile includes the .gemspec file, so they'll all be in the Gemfile.lock file | 17:13 |
ssam2 | (the tool uses Bundler internally so the versions in Gemfile.lock do get honoured) | 17:14 |
rdale | yes, but i don't think most rails projects would be packaged as gems and wouldn't have a .gemspec would they? | 17:14 |
ssam2 | rdale: I wish I'd realised this a month ago. :( | 17:14 |
rdale | yes, i'm currently studying what it does with bundler | 17:14 |
ssam2 | it's not a hard change to make, code-wise, but I don't think I have more time to work on this | 17:14 |
rdale | well i can help i hope | 17:15 |
ssam2 | I think it just needs a new type of importer adding which takes a repo URL instead of a Gem name | 17:15 |
ssam2 | one type of importer can 'chain' to another type, so it could pass on the work of importing the dependencies to the existing 'rubygems' importer | 17:15 |
ssam2 | since they will all be Gems | 17:15 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 17:48 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:57 | |
pedroalvarez | wow, looks like weston-ivi-shell has been finally merged in weston upstream | 17:59 |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:02 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:07 | |
radiofree | yeah, but that version doesn't work with wayland-ivi-extension | 18:08 |
radiofree | http://lists.genivi.org/pipermail/genivi-ivi-layer-management/2014-December/002294.html | 18:09 |
pedroalvarez | heh | 18:13 |
*** rdale_ [~quassel@147.Red-2-136-156.dynamicIP.rima-tde.net] has joined #baserock | 18:47 | |
*** rdale__ [~quassel@142.Red-79-159-240.staticIP.rima-tde.net] has joined #baserock | 18:49 | |
*** rdale [~quassel@192.Red-79-144-57.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 18:50 | |
*** rdale_ [~quassel@147.Red-2-136-156.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] | 18:51 | |
*** rdale__ [~quassel@142.Red-79-159-240.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 18:56 | |
*** rdale [~quassel@235.Red-95-121-245.dynamicIP.rima-tde.net] has joined #baserock | 18:59 | |
*** rdale_ [~quassel@219.Red-88-13-185.dynamicIP.rima-tde.net] has joined #baserock | 19:04 | |
*** rdale [~quassel@235.Red-95-121-245.dynamicIP.rima-tde.net] has quit [Ping timeout: 250 seconds] | 19:05 | |
*** rdale [~quassel@169.Red-88-8-223.dynamicIP.rima-tde.net] has joined #baserock | 19:06 | |
*** rdale_ [~quassel@219.Red-88-13-185.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 19:09 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 19:11 | |
*** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:56 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 19:56 | |
petefoth_ is now known as petefoth | 19:56 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 19:57 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:58 | |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:17 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!