| *** zoli__ has quit IRC | 00:57 | |
| *** zoli__ has joined #baserock | 05:50 | |
| *** paulw has joined #baserock | 06:12 | |
| *** mariaderidder has joined #baserock | 08:02 | |
| *** bashrc_ has joined #baserock | 08:08 | |
| *** mdunford has joined #baserock | 08:12 | |
| *** jonathanmaw has joined #baserock | 08:18 | |
| *** ssam2 has joined #baserock | 08:32 | |
| *** ChanServ sets mode: +v ssam2 | 08:32 | |
| *** edcragg has joined #baserock | 08:51 | |
| *** gary_perkins has joined #baserock | 08:56 | |
| paulsherwood | ssam2: hi there.... how was the conference? | 08:57 |
|---|---|---|
| ssam2 | paulsherwood: hello | 09:02 |
| ssam2 | it was interesting | 09:02 |
| ssam2 | got various interesting questions and pointers after my Baserock talk | 09:02 |
| ssam2 | pointers included: NixOS (of course), but also something OpenStack develop called 'diskimagebuilder' | 09:03 |
| ssam2 | someone also asked about integration with Packer, which would be cool to have | 09:04 |
| ssam2 | I didn't get my head around diskimagebuilder yet, but it seems to have some useful overlap with Baserock tools: https://github.com/openstack/diskimage-builder | 09:04 |
| ssam2 | seems to be used by OpenStack test infrastructure to build OS images that are then used to test OpenStack (perhaps you could call it 'inception testing') | 09:05 |
| paulsherwood | 'inception testing'... wow! :) | 09:09 |
| paulsherwood | i like it | 09:10 |
| paulsherwood | i should google packer properly too :) | 09:10 |
| paulsherwood | was your talk well received, do you think? | 09:10 |
| ssam2 | http://packer.io/ | 09:10 |
| ssam2 | I think it was, there wasn't a huge crowd, but lots of well-informed questions after | 09:11 |
| ssam2 | so a lot of people are interested in the same area | 09:11 |
| paulsherwood | excellent | 09:11 |
| ssam2 | it was videod, hopefully the video will be out before too long. although with community-led conferences there can often be a long gap before the organisers have any energy to edit videos :) | 09:12 |
| paulsherwood | editing videos is surprisingly timeconsuming and dull :) | 09:13 |
| *** lachlanmackenzie has joined #baserock | 09:14 | |
| tiagogomes_ | I have used diskimage-builder to build images for Ironic | 09:19 |
| * edcragg too, never thought it would be comparable to baserock | 09:20 | |
| ssam2 | it's not really comparable to "Baserock", as "Baserock" refers to a project rather than a specific piece of software | 09:21 |
| edcragg | ok, morph/ybd | 09:21 |
| ssam2 | how does it compare with the disk image creation functionality we have? | 09:21 |
| ssam2 | it's cool that you already know it, anyway | 09:22 |
| edcragg | baserock assembles the os from scratch, where diskimagebuilder, as far as i know, makes ironic disk images, from distribution releases | 09:22 |
| ssam2 | right, but how does it compare with `morph deploy`? | 09:23 |
| ssam2 | I know it doesn't overlap at all with `morph build` | 09:23 |
| edcragg | i guess it's equivalent to rawdisk.write | 09:23 |
| edcragg | ironic itself is a deployment tool | 09:24 |
| ssam2 | seems to have a lot more code than rawdisk.write! and a lot of it is shell.. :( | 09:24 |
| paulsherwood | heh | 09:25 |
| paulsherwood | less code for the win :) | 09:25 |
| ssam2 | one of the main developers of diskimage-builder was in the talk and was saying it might be nice if Baserock could be integrated with it in the same way distros like Ubuntu are. Not sure how easy that would be | 09:25 |
| ssam2 | he said it could allow us to reuse some of OpenStack's infrastructure more easily | 09:25 |
| paulsherwood | we could look at that. aren't we already able to spin up our own OpenStack infrastructure trivially though? | 09:26 |
| edcragg | that sounds feasible, it seems to use plugins/modules for different OSs | 09:26 |
| edcragg | do we have baserock ironic images already? | 09:28 |
| ssam2 | paulsherwood: we can deploy an OpenStack cloud easily. But they have lots of components doing automated integration and testing, which I don't know much about at present | 09:29 |
| paulsherwood | tempest etc... do our default definitions include any of that? | 09:29 |
| paulsherwood | pedroalvarez: ^^ | 09:29 |
| ssam2 | I think we have tempest already] | 09:29 |
| * rjek assumes this is not related to reading the contents of a CRT from a distance | 09:30 | |
| paulsherwood | i think we need to understand this inception testing concept better maybe. | 09:30 |
| ssam2 | seems to be called TripleO: https://wiki.openstack.org/wiki/TripleO | 09:30 |
| paulsherwood | it's like turtles all the way down... what tests the tests... what's the infrastructure for the next infrastructure? | 09:31 |
| ssam2 | maybe we could run it all on CloudFoundry | 09:32 |
| ssam2 | (joke) | 09:32 |
| paulsherwood | lol | 09:34 |
| paulsherwood | and run that on Azure? | 09:34 |
| ssam2 | we have a lot to learn from the financial industry. We could sell this as "cloud derivatives" and make a fortune | 09:35 |
| dabukalam | My understanding is that tripleO is no longer an ongoing project | 09:36 |
| ssam2 | hmm, OK | 09:36 |
| paulsherwood | lol | 09:36 |
| paulsherwood | https://twitter.com/codethink/status/624151322896527360 | 09:37 |
| paulsherwood | at a non-openstack conference i saw a talk which included claims that OpenStack didn't have a solid way to deal with updates to itself yet... do we know if that's true? | 09:40 |
| nowster | ssam2: The reason for libogg-git.lorry was because we already had a libogg.lorry (fixed to tarball). I hadn't realised we now had an inconsistently named ogg.lorry too. | 09:45 |
| ssam2 | nowster: ah, I see | 09:46 |
| pedroalvarez | I still type "open" and press tab when I don't remember where I wanted to go in a definitions.git checkout | 10:48 |
| pedroalvarez | I've been working on openstack & baserock for too long | 10:49 |
| *** bjdooks_ is now known as bjdooks | 11:20 | |
| *** lachlanmackenzie has quit IRC | 12:05 | |
| *** bwh_ is now known as bwh | 12:15 | |
| *** mdunford has quit IRC | 12:35 | |
| *** lachlanmackenzie has joined #baserock | 13:00 | |
| *** jonathanmaw has quit IRC | 13:32 | |
| *** jonathanmaw has joined #baserock | 13:35 | |
| *** jonathanmaw has quit IRC | 13:37 | |
| *** jonathanmaw has joined #baserock | 13:38 | |
| rjek | So. linux-user-chroot apparently drops the ability to use chown, for good reason (it's designed to let untrusted users have chroots without letting them easily escalate their privilege using the S bit) | 13:39 |
| *** jonathanmaw has quit IRC | 13:40 | |
| rjek | However, this makes it impossible to build and "install" stuff that needs to install files with different ownerships. | 13:40 |
| rjek | This is very sadmaking. | 13:40 |
| rjek | Is there a work-around? | 13:40 |
| rjek | Other than the hideousness that would be "do it on first boot" | 13:41 |
| rjek | (doing it on first boot might be a reproducability problem, and it requires a mutable root file system) | 13:42 |
| ssam2 | rjek: not got a clear answer, but in general I think setting permissions is an 'integration' or 'deploy' thing rather than a 'build' thing | 13:47 |
| ssam2 | you could do it in a .configure extension | 13:47 |
| ssam2 | and I think in theory you should be able to do it directly in the chunk's .morph file with system-integration-commands | 13:47 |
| rjek | ssam2: So one must reverse-engineer a piece of software's build/install targets and reproduce them somewhere else for deploy-time? | 13:47 |
| ssam2 | but I have a feeling that won't work | 13:47 |
| pedroalvarez | ssam2: nope, system integration commands also run in l-u-c | 13:48 |
| ssam2 | rjek: if you're depending on it settings user permissions in 'make install', yes. what software is doing that, out of interest? | 13:48 |
| ssam2 | sounds a bit broken, since you'd need to be root to 'make install' | 13:48 |
| *** jonathanmaw has joined #baserock | 13:48 | |
| rjek | Lots. :) | 13:48 |
| rjek | That's what the "install" command in coreutils is for, after all :) | 13:49 |
| ssam2 | that's not really an accurate statement | 13:49 |
| ssam2 | but it does allow you to change ownership, if you want | 13:49 |
| rjek | But, fundamentally, one must reimplement a product's "make install" target such that it occurs at deploy time? | 13:49 |
| ssam2 | are you asking as a general question, or in the context of a specific piece of software? | 13:50 |
| ssam2 | i've packaged lots of stuff in Baserock, and have never had to do that | 13:50 |
| rjek | Both, nagios and exim in this situation | 13:50 |
| ssam2 | ok | 13:50 |
| ssam2 | from what i've heard, exim will be a nightmare no matter what the tooling does :) | 13:50 |
| rjek | Lots of software is a nightmare. | 13:51 |
| ssam2 | indeed. Well, to answer your question, yes, you have to set ownership at deploy time instead | 13:51 |
| rjek | OK, thanks. Is there a plan to make this easier? | 13:51 |
| ssam2 | it's tricky | 13:52 |
| pedroalvarez | I'd like to have one | 13:52 |
| pedroalvarez | but indeed is tricky | 13:52 |
| ssam2 | some people want the build tool to be able to run as non-root | 13:52 |
| rjek | fakeroot? | 13:52 |
| rjek | That's how Debian solves this | 13:52 |
| ssam2 | which basically makes this impossible without fakeroot, which is a fragile, complex hack | 13:52 |
| ssam2 | it kind of goes against the "work with upstreams, not against them" idea | 13:52 |
| rjek | Or perhaps a vm | 13:52 |
| rjek | Upstreams are humans, thus awful. | 13:53 |
| ssam2 | software is made by humans, so that is awful too | 13:53 |
| rjek | Indeedu | 13:53 |
| rjek | -u | 13:53 |
| ssam2 | I'd prefer to write patches for projects which expect that `make install` to always have root permissions, so that they don't assume that | 13:53 |
| rjek | Sadly for many pieces of software root is non-negotiable as it's a fundamental assumption on what they are doing | 13:55 |
| ssam2 | it seems quite wrong to me that system-integration commands can't set user permissions. If they could, it'd mean that building a system image would require root | 13:55 |
| rjek | ie, installing files with differing ownerships | 13:55 |
| ssam2 | i'm interested in actual data on that. like I said, we've got a long way without support for this | 13:55 |
| ssam2 | i'm not disagreeing, I just want an idea of the scale of things | 13:56 |
| rjek | exim, for example, need a dedicated user and group, needs to create directories for mail spool that are owned by that user and have the sticky bit set, and sometimes needs to install a setuid root executable. | 13:56 |
| rjek | And it needs all that to function at all | 13:56 |
| ssam2 | systemd has some nice tricks for solving all but the last part | 13:57 |
| ssam2 | well, tools rather than tricks | 13:57 |
| rjek | I'm sure systemd has all sorts of fragile and ill-documented tricks :) | 13:57 |
| ssam2 | systemd-tmpfiles exists to create directories that are empty and owned by a specific user | 13:57 |
| ssam2 | http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html | 13:58 |
| ssam2 | and systemd-sysusers will create users and groups on first boot | 13:58 |
| rjek | Yeah, first boot root file system modifications. | 13:58 |
| ssam2 | http://www.freedesktop.org/software/systemd/man/systemd-sysusers.html | 13:58 |
| ssam2 | I don't think modifying the root file system on first boot is a bad thing | 13:59 |
| ssam2 | modifying /usr on first boot would be bad | 13:59 |
| rjek | We'll have to disagree there then :) | 13:59 |
| ssam2 | what am I missing? | 13:59 |
| rjek | You're assuming the root file system is mutable | 13:59 |
| rjek | Or that you want it to be mutable | 13:59 |
| ssam2 | i'm assuming /var and /etc are mutable | 14:00 |
| ssam2 | why wouldn't they be? | 14:00 |
| rjek | why should /etc be mutable? | 14:00 |
| ssam2 | because it's for runtime configuration | 14:00 |
| rjek | Anyway. Thanks. | 14:00 |
| * radiofree is currently working on a system where /etc isn't mutable | 14:09 | |
| rjek | At least half the embedded systems I've worked on don't have mutable /etc | 14:12 |
| ssam2 | I stand corrected | 14:12 |
| rjek | And some of them didn't even have mutable /var | 14:12 |
| ssam2 | did they have files owned by multiple users? :) | 14:13 |
| rjek | Yes. | 14:13 |
| rjek | Because running everything as root is loopy | 14:13 |
| paulsherwood | seems i find myself agreeing with rjek again in spite of myself :) | 14:15 |
| rjek | Agreeing with me is perfectly natural, paulsherwood. | 14:15 |
| paulsherwood | this does seem like a hole we need to fill | 14:15 |
| ssam2 | I tried to write it up here: https://storyboard.baserock.org/#!/story/54 | 14:25 |
| ssam2 | contributions welcome to turn it from confused nonsense into an actual useful story | 14:25 |
| pedroalvarez | Ok, I understand why cloudfoundry, when generating the disk image for the stemcell, they set a partition offset for installing grub later. | 14:55 |
| pedroalvarez | why this is not needed with extlinux in baserock? | 14:55 |
| ssam2 | i don't really know. maybe extlinux is small enough to fit in the boot sector? | 14:59 |
| pedroalvarez | that makes sense | 15:00 |
| pdar | heya, how long should I expect it to take for ybd to build a build sytem? | 15:03 |
| tiagogomes_ | is not because the OS files are in btrfs subvolumes, and the booloader is being installed outside the subvolumes? | 15:03 |
| tiagogomes_ | So you don't need an offset for your data | 15:04 |
| tiagogomes_ | As btrfs takes care that the subvolumes files are not overwritten when writing to the top level | 15:05 |
| ssam2 | pdar: not sure, but if you're going from scratch, hours | 15:10 |
| pedroalvarez | that, and cache.baserock.org (and maybe more things), is why I still prefer morph :) | 15:12 |
| pdar | alas, I started at 10am ish, I'm on step 5/232/241. | 15:13 |
| pdar | I am too used to the lightning speeds of cache.baserock.org | 15:14 |
| tiagogomes_ | pedroalvarez, if Paul reads that... | 15:14 |
| tiagogomes_ | step 5/232/241 ? | 15:15 |
| pedroalvarez | indeed, wha is the 5? | 15:15 |
| pedroalvarez | +t | 15:15 |
| pdar | ?? | 15:15 |
| tiagogomes_ | -> 5 <- /232/241 | 15:15 |
| pedroalvarez | pdar: we don't understand the meaning of that | 15:16 |
| pedroalvarez | i would understand 5/232 | 15:16 |
| pedroalvarez | or 232/241 | 15:16 |
| pdar | I assume where I am in the number of the things to build? | 15:16 |
| pdar | Its my first try of ybd | 15:16 |
| pdar | 15-07-23 14:59:33 [5/232/241] [linux-api-headers] Starting build | 15:16 |
| tiagogomes_ | you started a build at 10am and it is still on build-essential !!? | 15:17 |
| pdar | I had to stop and start it around 2pm | 15:18 |
| pdar | So, I was looking at using ybd as I wanted to build something in a docker container, I didnt see that we already had instructions for making a baserock docker thing, I guess I can do that and just use morph in a baserock docker container instead | 15:23 |
| *** paulw has quit IRC | 15:33 | |
| pedroalvarez | hehe | 15:33 |
| pedroalvarez | so, concourse uses docker to set up the environment for testing? | 15:34 |
| pdar | From what I've looked at you seem to run all your bits in in docker-containers | 15:37 |
| *** zoli__ has quit IRC | 15:37 | |
| *** zoli__ has joined #baserock | 15:38 | |
| pedroalvarez | if this is going to be to build stemcells, it might be better to assume Ubuntu | 15:41 |
| pdar | I think I should be able to use a different docker container for the construction of the stemcell itself. And use a baserock container to construct the os-image that'll be used to make said stemcell. | 15:45 |
| pedroalvarez | :) | 15:47 |
| ssam2 | pdar: it might have taken a long time because of having to clone all the Git repos before it did anything else | 15:48 |
| ssam2 | pdar: if so, you could gain a bit of speed by proving that cache yourself | 15:48 |
| tiagogomes_ | this may be of interest here: https://mail.gnome.org/archives/desktop-devel-list/2015-July/msg00012.html | 15:48 |
| ssam2 | interesting | 15:49 |
| ssam2 | i've always wanted components to come with 'run this component in a testing environment' scripts | 15:49 |
| ssam2 | since each component seems to need isolating from the host in different ways | 15:50 |
| ssam2 | like this one: https://git.gnome.org/browse/tracker/tree/utils/sandbox/tracker-sandbox.py | 15:50 |
| ssam2 | (although that's quite a complex example, I imagined something simpler) | 15:50 |
| *** fay_ has quit IRC | 15:54 | |
| tiagogomes_ | but wouldn't be enough when you need to test changes in more than one component | 15:54 |
| pdar | ssam2: Ooh, how could I populate the cache myself? | 15:57 |
| ssam2 | pdar: it's just a bunch of files under /src/cache/gits | 15:57 |
| ssam2 | a bunch of Git repos in a specific format, to be more precise | 15:57 |
| ssam2 | the format is the same one Morph uses | 15:57 |
| ssam2 | so if you've used YBD anywhere else, or used Morph anywhere else, just copy all the git__git_baserock_org_xxx directories you need into the system where you're running the build | 15:58 |
| ssam2 | or make them available in some other way | 15:58 |
| pedroalvarez | pdar: also, for speed, you can try to use another trove, if you have one lorrying from g.b.o | 15:58 |
| *** mariaderidder has quit IRC | 16:10 | |
| *** jonathanmaw has quit IRC | 16:27 | |
| ssam2 | the dream has finally come true! | 16:45 |
| ssam2 | https://gerrit.baserock.org/1000 | 16:45 |
| ssam2 | next stop: 10000 | 16:45 |
| *** bashrc_ has quit IRC | 16:54 | |
| pedroalvarez | that means gerrit has been accepted by the baserock community :) | 17:14 |
| *** edcragg has quit IRC | 17:42 | |
| *** lachlanmackenzie has quit IRC | 18:43 | |
| *** ssam2 has quit IRC | 19:09 | |
| *** zoli__ has quit IRC | 19:16 | |
| *** zoli__ has joined #baserock | 19:16 | |
| *** zoli__ has quit IRC | 19:54 | |
| *** edcragg has joined #baserock | 21:44 | |
| *** zoli__ has joined #baserock | 22:05 | |
| *** zoli__ has quit IRC | 22:16 | |
| *** edcragg has quit IRC | 23:05 | |
| *** sebh has quit IRC | 23:32 | |
| *** Zara_ has quit IRC | 23:32 | |
| *** kejiahu has quit IRC | 23:32 | |
| *** sebh has joined #baserock | 23:32 | |
| *** kejiahu has joined #baserock | 23:33 | |
| *** petefotheringham has quit IRC | 23:33 | |
| *** Zara has joined #baserock | 23:33 | |
| *** jmacs has quit IRC | 23:33 | |
| *** petefotheringham has joined #baserock | 23:33 | |
| *** jmacs has joined #baserock | 23:33 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!