| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:00 | |
| *** locallycompact [~lc@146.200.27.158] has joined #baserock | 07:37 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:58 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 08:02 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:02 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 260 seconds] | 08:14 | |
| *** jonathanmaw [~jonathanm@82.68.191.81] has joined #baserock | 08:20 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:25 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:55 | |
| *** locallycompact [~lc@146.200.27.158] has quit [Ping timeout: 272 seconds] | 08:55 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:18 | |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:34 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 10:33 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 10:43 | |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 255 seconds] | 12:20 | |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has joined #baserock | 12:22 | |
| persia | I was just updating my definitions, and saw the new "mason" directory. Looking a bit more, there seem to also be directories for distbuild, gitlab-ci-runner, gitlab-server, genivi-devl-system-arm7, and vagrant-files. | 12:39 |
|---|---|---|
| persia | Most of these seem to have a similar format, but mason is different, although the contents don't seem too dissimilar: is mason special in some way that blocks using the manifest format? | 12:40 |
| tlsa | 1. I was unaware of a standard format, 2. I think the plan is to put it in a chunk eventually | 12:41 |
| persia | Also, do we expect the set of these to proliferate within the definitions repository? If so, why are some other systems (e.g. trove) not done this way? If not, why do we have so many? | 12:41 |
| persia | tlsa: Heh, yeah, documentation is sparse :) I just discovered the apparent standard format today when I went looking as a result of seeing the "mason" directory . | 12:42 |
| persia | tlsa: If it goes in a chunk: is there a reason to have that be eventually, rather than sooner? It strikes me that if these don't belong in definitions, we probably want to block such additions on review, as otherwise everyone downloads the history in the future, containing temporary data that won't be relevant or interesting. | 12:44 |
| persia | On an only slightly related topic: does the content of image-package-example/ still have relavance? Is there a reason someone would not want to use morph for this? | 12:45 |
| tlsa | some could move to a chunk (mason.sh, mason-report.sh), but most of the rest is to configure the deployment, so would likely stay there | 12:45 |
| persia | So you think we expect these to proliferate? Any idea why we don't have such a thing for trove? | 12:46 |
| tlsa | no idea | 12:47 |
| tlsa | we used the existing distbuild and trove cluster morphologies as a template for the mason work | 12:48 |
| persia | That seems like a sensible place to start. Perhaps it's just lack of docs that makes it different. | 12:49 |
| persia | In my mind, ideally we'd either have it in a chunk (like trove-setup), or use the semi-standard model (like distbuild/manifest and friends). But I have no idea which is the right way, or why one might choose one over the other. | 12:56 |
| SotK | the "standard format" uses the install-files configure extension, but the mason folder appears to just be used by mason.configure, hence the different layout | 13:05 |
| persia | Aha! | 13:15 |
| persia | So the expectation is that we will have lots of these folders: as many as one per system, to support install-files? | 13:16 |
| richard_maw | currently, yes, though my preferred approach is that when appropriate there is a configuration extension that generates the config, rather than dropping it in with install-files | 13:18 |
| persia | Also, can a deployment use multiple configure extensions, so mason could use install-files for the file installs, and then do it's magic? | 13:19 |
| richard_maw | yes | 13:19 |
| persia | richard_maw: So when defining a system, if I want deployment-time magic, I should generally expect to write a configuration extension, and do everything therein? | 13:20 |
| richard_maw | persia: if there's a brand new thing that needs to be configured, yes, though I'd like to make it possible for chunks to be able to provide configuration extensions | 13:20 |
| persia | Ah, so systems wouldn't generally need this sort of thing? | 13:21 |
| persia | I like that idea. | 13:21 |
| richard_maw | the reason why we copy files in with configuration extensions though is that the install-files API is arcane and unforgiving | 13:21 |
| persia | Ah. Yes, I can see how one would wish to avoid that :) | 13:22 |
| *** liw-orc [~liw@access.ducie-dc1.codethink.co.uk] has quit [Quit: Coyote finally caught me] | 13:54 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 14:59 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 15:07 | |
| SotK | Is there any reason why morph3 should continue to be called morph3 once morph2 is gone? | 15:31 |
| Kinnison | I'd have a final patch which renames it, in your series, if possible | 15:32 |
| SotK | that was my plan if no-one had any objections to renaming it | 15:32 |
| SotK | s/morph3/morphology/g? | 15:32 |
| Kinnison | morphlib.morphology.Morphology is a tad long, but perhaps | 15:33 |
| SotK | morph3 is only ever instantiated by morphloader or some parts of the test suite, so its not often morphlib.morphology.Morphology would be needed | 15:35 |
| Kinnison | okay | 15:36 |
| Kinnison | works for me then | 15:36 |
| tlsa | what are morph2 and 3? | 15:38 |
| Kinnison | the reimplementation and subsequent reimplementation of morph.Morphology | 15:39 |
| Kinnison | yay hysterical raisins | 15:39 |
| SotK | part of the codebase uses morph3, and part uses morph2 for hysterical raisins too, so they both hung around | 15:39 |
| tlsa | morph.Morphology's a port of morph? | 15:39 |
| tlsa | ok | 15:40 |
| tlsa | s/port/part/ | 15:40 |
| Kinnison | yes | 15:41 |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 16:48 | |
| *** jonathanmaw [~jonathanm@82.68.191.81] has quit [Quit: Leaving] | 16:59 | |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 260 seconds] | 17:34 | |
| richard_maw | I sent a patch for build not needing to create temporary build branches when it doesn't need to: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-August/007474.html | 22:08 |
| richard_maw | I'll probably take a look at paulsherwood's workflow tweaks mail and the morph2 removal this weekend | 22:13 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!