| *** wdutch has quit IRC | 02:19 | |
| *** gtristan has joined #baserock | 04:39 | |
| *** rdale has joined #baserock | 05:29 | |
| *** toscalix has joined #baserock | 07:40 | |
| *** fay has joined #baserock | 07:53 | |
| *** fay is now known as faybrocklebank | 07:53 | |
| *** gtristan has quit IRC | 08:10 | |
| *** CTtpollard has quit IRC | 08:26 | |
| *** CTtpollard has joined #baserock | 08:30 | |
| *** gtristan has joined #baserock | 08:38 | |
| *** franred has quit IRC | 08:56 | |
| *** franred has joined #baserock | 08:56 | |
| *** benbrown2 is now known as benbrown_ | 08:57 | |
| *** CTtpollard has quit IRC | 09:00 | |
| *** CTtpollard has joined #baserock | 09:02 | |
| gtristan | So I think I need to understand a bit more how 'extensions' work | 09:04 |
|---|---|---|
| * paulsher1ood would like to answer locallycompact's question, but he's not here | 09:05 | |
| gtristan | What I'd like to do, is run some code in a chroot of a built system, with a given artifact staged at a given location; say it's already built and I want it to appear again as /${chunkname}.inst | 09:06 |
| * pedroalvarez reads gtristan | 09:07 | |
| gtristan | this is so that I could run tools (specifically rpmbuild) that are built in the system, without relying on host tools, to operate on a given chunk | 09:07 |
| *** tiagogomes has joined #baserock | 09:07 | |
| gtristan | that extension basically just has to parse the metadata for the chunk, generate an rpm spec file according to the splitting rules and build a package | 09:08 |
| * gtristan is thinking 'extensions' is the way to go, because it clearly should not be a first class citizen feature for ybd | 09:08 | |
| *** lc_ has joined #baserock | 09:09 | |
| pedroalvarez | paulsher1ood: ^ | 09:09 |
| pedroalvarez | gtristan: so, you described something like install the same chunk in 2 different locations? | 09:10 |
| *** lc_ is now known as locallycompact | 09:10 | |
| gtristan | pedroalvarez, any idea how I would go about this ? specifically... can I have an extension that runs code in a chroot sandbox ? and how would such a thing be invoked from the cluster ? | 09:10 |
| gtristan | pedroalvarez, kind of sort of... I mean to stage an artifact as well as having the entire built system staged | 09:11 |
| gtristan | pedroalvarez, I guess it doesnt really have to be natively understood by ybd... so long as the extension itself has the ability to call back into functionality that ybd provides | 09:13 |
| pedroalvarez | with a configure extension you can run any code you want. They are basically a program that take the location of the decompressed system rootfs as an argument, and you can do whatever with it | 09:14 |
| gtristan | pedroalvarez, so say there is some already existing semantic to run an 'extension' from a cluster... and that extension would just need to run some code asking ybd to "please stage the entire system, and also put this artifact here, and run this code in the sandbox" | 09:14 |
| pedroalvarez | that ^ sounds a bit tricky | 09:15 |
| gtristan | the configure extension is a good start | 09:15 |
| pedroalvarez | i wonder if we have the functionality you need already implemented | 09:16 |
| pedroalvarez | how many artifacts will you need? 1? 10? 100? | 09:16 |
| gtristan | well, all of them; but I was thinking it should be something I should be able to do one at a time | 09:17 |
| pedroalvarez | I'm wondering if the implementation of subsystems deployment (deployment of a system inside of a system) combined with the partial deployments (deploy only some parts of a system) will give you this functionality | 09:17 |
| gtristan | sounds like a pretty intense operation, but considering that staging is usually done with hardlinks, shouldnt be too bad | 09:17 |
| gtristan | I guess the subsystems deployment thing is something we're looking into especially to avoid the usage of host tooling in deployment phase ? | 09:19 |
| pedroalvarez | cannot be as bad as building webkit twice | 09:19 |
| gtristan | pedroalvarez, is subsystems deployment something that already exists ? | 09:20 |
| pedroalvarez | yes, it does | 09:20 |
| gtristan | nice, are we using it now to kill that syslinux/btrfs/requiring a baserock vm problem ? | 09:20 |
| pedroalvarez | the classic and original example for subsystems clusters/initramfs-test.morph | 09:21 |
| pedroalvarez | not related to killing syslinux/btrfs/vms | 09:21 |
| pedroalvarez | it only gives you the ability of putting a system inside of a system at deploytime | 09:22 |
| gtristan | hmmm, ok so we *could* be using that to kill off the host tool dependencies | 09:22 |
| pedroalvarez | i see your point now | 09:22 |
| pedroalvarez | is that related to your goal? so that you could run things against some artifacts using tools that are in another system? | 09:23 |
| gtristan | pedroalvarez, yes that is | 09:24 |
| pedroalvarez | well, I think you had a brilliant idea :) | 09:24 |
| gtristan | pedroalvarez, I want to run the rpmbuild tool that is built in that particular system, to package rpms for each artifact in that system | 09:24 |
| * gtristan is not sure how that initramfs cluster is really working | 09:25 | |
| pedroalvarez | that problem may be a bit more complicated | 09:25 |
| * gtristan is looking at extensions/initramfs.write | 09:25 | |
| pedroalvarez | naw, don't look at that | 09:25 |
| pedroalvarez | the cluster says that the subsystem "initramfs" will be deployed at location boot/initramfs.gz of the main system | 09:26 |
| pedroalvarez | which is the main point, deploying things inside other systems before deploying them | 09:27 |
| gtristan | I dont understand how that cluster says that :-/ | 09:27 |
| pedroalvarez | I'll be busy the next 30 min or so, ill be back later | 09:28 |
| gtristan | it says basically: { deploy { initramfs { type = extensions/initramfs, location = boot/initramfs.gz } } } | 09:28 |
| pedroalvarez | yes | 09:28 |
| pedroalvarez | but that is a subsystem | 09:28 |
| pedroalvarez | (see previous "subsystems" keyword) | 09:29 |
| gtristan | ohhh | 09:29 |
| gtristan | oh | 09:29 |
| gtristan | ok so the shell commands in extensions/initramfs.write are executed inside the deployed system ? | 09:29 |
| pedroalvarez | nope | 09:30 |
| gtristan | pedroalvarez, ok I'll read what the subsystems keyword does in ybd and try to figure it out | 09:31 |
| gtristan | pedroalvarez, I think that might be most of what I need, and I may need to add some core semantics saying "Please run this code in the sandbox" | 09:32 |
| gtristan | that should be very doable, seeing we already do it for system-integration commands | 09:33 |
| *** ctbruce has joined #baserock | 09:53 | |
| *** ctbruce has quit IRC | 09:54 | |
| *** ctbruce has joined #baserock | 09:54 | |
| *** ctbruce has quit IRC | 09:56 | |
| *** ctbruce has joined #baserock | 09:59 | |
| *** jonathanmaw has joined #baserock | 10:01 | |
| *** jonathanmaw has quit IRC | 10:04 | |
| *** anahuelamo_ has quit IRC | 10:06 | |
| *** anahuelamo has joined #baserock | 10:06 | |
| *** CTtpollard has quit IRC | 10:12 | |
| *** toscalix has quit IRC | 10:12 | |
| *** CTtpollard has joined #baserock | 10:12 | |
| *** toscalix has joined #baserock | 10:13 | |
| *** anahuelamo has quit IRC | 10:13 | |
| *** anahuelamo has joined #baserock | 10:13 | |
| *** paulwaters_ has joined #baserock | 10:14 | |
| *** ctbruce has quit IRC | 10:23 | |
| *** ctbruce has joined #baserock | 10:23 | |
| *** franred has quit IRC | 10:26 | |
| *** franred has joined #baserock | 10:26 | |
| *** ctbruce has quit IRC | 10:27 | |
| *** ctbruce has joined #baserock | 10:27 | |
| * paulsher1ood would like to see extensions as some kind of 'deploylib', rather than in definitions | 10:30 | |
| paulsher1ood | but maybe i'm missing the point | 10:31 |
| paulsher1ood | and maybe the exensions are too coupled to definitions specifics to make that possible/sensible | 10:31 |
| locallycompact | Suggestion: Buildable type class that has 'build-depends' and a set of execution instructions that transform input -> output. Assemblage and Chunk are both Buildable. | 10:33 |
| pedroalvarez | gtristan: note that write/configure extensions are not using any sandboxing | 10:33 |
| paulsher1ood | locallycompact: many output types are possible... | 10:34 |
| SotK | paulsher1ood: we attempted that approach when first moving the extensions out of morph, but decided that most of them aren't useful when not in the definitions repository | 10:34 |
| paulsher1ood | SotK: ack | 10:35 |
| locallycompact | paulsher1ood, ? | 10:35 |
| locallycompact | they all output a filesystem no? | 10:35 |
| paulsher1ood | rpm, img, tar, etc... | 10:35 |
| paulsher1ood | yes, they're all of class 'thing' too | 10:36 |
| locallycompact | chunk goes source -> filesystem as artifact assemblage goes staged artifacts -> filesystem as artifact | 10:36 |
| locallycompact | this is long before you get to a tarball | 10:36 |
| locallycompact | or any of that | 10:36 |
| paulsher1ood | locallycompact: we're talking about extensions | 10:36 |
| locallycompact | right | 10:36 |
| gtristan | paulsher1ood, I had the same thoughts earlier on, now I think there are 2 classes of extensions; extensions that should probably be built in to ybd as features, and extensions that are related to a specific system (i.e. this rpmbuild thing would really only be useful for a specific project / definitions tree) | 10:37 |
| paulsher1ood | extensions are *after* we've got to a tarball | 10:37 |
| locallycompact | ? like what | 10:37 |
| paulsher1ood | rpm, img, rootfs etc... | 10:37 |
| locallycompact | ok this is worlds away from what I'm thinking of | 10:37 |
| gtristan | Another thought I had was, I wonder if some of the extensions we do have could instead be written out like we do build instructions in the yaml directly | 10:37 |
| SotK | gtristan: which extensions fit into the former catefory? | 10:37 |
| paulsher1ood | locallycompact: i'm commenting on gtristan's discussion with pedroalvarez | 10:38 |
| gtristan | SotK, well, install-files for example is vastly used in all systems (although arguably should not exist at all :-/) | 10:38 |
| paulsher1ood | locallycompact: i had assumed your Suggestion was a contribution to that discussion | 10:39 |
| gtristan | SotK, tarring up a sysroot seems like a common enough feature | 10:39 |
| locallycompact | I'm thinking of these things configuration-extensions: | 10:39 |
| locallycompact | They're in the system definitions | 10:39 |
| locallycompact | - extensions/set-hostname | 10:39 |
| locallycompact | - extensions/add-config-files | 10:39 |
| paulsher1ood | locallycompact: do you still need to understand what assembly.claim is doing? | 10:39 |
| locallycompact | yeah | 10:39 |
| SotK | gtristan: a number of the extensions used to be built in to morph, we extracted them out of morph and into definitions to avoid definitions being tied to a single build tool | 10:40 |
| SotK | I'd be disappointed to undo that work and retie definitions to a single build tool again (albeit a different one) | 10:40 |
| paulsher1ood | ybd can run multi-instance, claim ensures only one thread is attempting to assemble foo at once.. it holds a foo.lock file | 10:40 |
| paulsher1ood | SotK: +1 | 10:40 |
| gtristan | SotK, yeah I had that discussion with Sam I recall; I'm still of the opinion that the build tool is the compiler and the definitions are the source, I dont like that those two dont have clean separation, and the compiler itself bleeds into the source | 10:41 |
| gtristan | it may contribute to definitions growing and growing | 10:42 |
| SotK | gtristan: A number of the extensions are closely related to the content of definitions rather than the build tool though. We originally planned to move them all into a separate library which the build tool would call out to, but we'd still have ended up with a bunch needing to be in definitions due to their implementation being so tied in with the definitions themselves. | 10:45 |
| SotK | We then decided that it made more sense to have all the extensions in one place (definitions) rather than keeping them separated across repositories. | 10:45 |
| gtristan | SotK, agreed, thats sort of the difference I was referring to; some extensions really should not be first class citizens in the formalism | 10:46 |
| gtristan | if they are common/useful enough, they should probably be features | 10:46 |
| SotK | gtristan: but that approach leads to code duplication across different build tools, or making one tool depend on another for its write extension code | 10:47 |
| gtristan | I honestly tend to think that code duplication is better, at least in the morph/ybd case I think code sharing could be achieved with common python libs | 10:48 |
| gtristan | having a well/strictly defined formalism for the definitions format is more desirable than saving lines of code in build tools | 10:49 |
| gtristan | but that is an entirely subjective point of view | 10:49 |
| * paulsher1ood agrees | 10:50 | |
| paulsher1ood | even though i'm fiercely in favour of less loc :) | 10:51 |
| * locallycompact mutters something about types | 10:51 | |
| paulsher1ood | locallycompact: this is about extensions. they're code, not data | 10:52 |
| locallycompact | all code is types | 10:52 |
| paulsher1ood | heh | 10:52 |
| *** lachlanmackenzie has joined #baserock | 10:54 | |
| SotK | assuming we did move the extensions out, what would we do with the "second class citizen" extensions (which iirc was most of them) | 11:00 |
| SotK | ? | 11:00 |
| paulsher1ood | pls give an example? | 11:01 |
| gtristan | SotK, I would favor factoring them into build instructions, or "deploy instructions" or system integration commands, if at all possible | 11:02 |
| gtristan | SotK, I would also favor doing more things in chunks, i.e. install-files gets nuked, and some chunks get added to various systems | 11:03 |
| gtristan | chunks after all are what add payload to a system | 11:03 |
| SotK | paulsher1ood: practically every non-trivial configure extension | 11:03 |
| leeming | since this is most likely a general mounting issue. I'm trying to integrate bwrap into sandboxlib but am hitting a lot of problems. Unsure I'm just stupid, the tests not great or bwrap doesn't do this - http://paste.baserock.org/raw/rojujureko | 11:04 |
| SotK | gtristan: what about something like the functionality of sshkeys.configure? | 11:04 |
| gtristan | SotK, interestingly, I cannot find anything in systems/ or clusters/ which mentions 'sshkeys' | 11:07 |
| gtristan | which leads me to think; it's actually deadcode ? | 11:07 |
| SotK | perhaps people began using install-files for ssh keys | 11:08 |
| gtristan | What I dont understand is what $SSHKEYS is in that extension | 11:09 |
| gtristan | it's a file... where ? | 11:09 |
| gtristan | if it's a file that is in definitions somewhere, then clearly that extension can just be a chunk | 11:09 |
| gtristan | itself | 11:09 |
| pedroalvarez | erm.. | 11:10 |
| pedroalvarez | you want to inject the ssh public key at deplyment time? | 11:10 |
| pedroalvarez | so that you inject yours, I inject mine, and we share all the built artifacts? | 11:10 |
| gtristan | pedroalvarez, as I dont understand how that configure extension was ever intended to work; I dont know. | 11:11 |
| pedroalvarez | hrm.. | 11:11 |
| pedroalvarez | you add in your cluster: | 11:11 |
| pedroalvarez | SSHKEYS: /path/to/my/.ssh/id_rsa.pub | 11:11 |
| gtristan | Ok well, if asked the question; honestly it looks like there needs to be some bridge between the definition of a chunk; and the context in which it is built | 11:13 |
| gtristan | So basically; what is a cluster ? | 11:14 |
| gtristan | a deployment, can be a deployment of anything | 11:14 |
| gtristan | So should a deployment really expose a feature that is specific to ssh ? | 11:14 |
| gtristan | Possibly the chunk needs to declaratively expose some variable that a user can effect at deployment time | 11:15 |
| gtristan | with the knowledge that they are deploying a system that has sshd ? | 11:15 |
| pedroalvarez | that was one of the ideas to implement | 11:15 |
| pedroalvarez | something like "some chunks give you access to some deployment extensions" | 11:15 |
| pedroalvarez | s/deployment// | 11:16 |
| gtristan | It could be simply that the user can export some variable (via some key file) that are read during system-integration | 11:16 |
| gtristan | then the sshd chunk could check for sshd.keys | 11:16 |
| gtristan | well, that's tricky because you dont have access to outside the system at that point | 11:17 |
| SotK | but then I couldn't reuse the system artifact from someone else's cache | 11:17 |
| gtristan | true | 11:17 |
| gtristan | messy | 11:17 |
| * SotK likes the "some chunks give you access to some deployment extensions" idea incidentally | 11:23 | |
| gtristan | leeming, you probably understand bwrap better at this point by; why would you expect the /data tmpfs to not be writable ? | 11:24 |
| leeming | because the root filesystem contains a /data directory and is mounted ro | 11:24 |
| leeming | but if i try to add in a writable version, it nukes the previous | 11:25 |
| gtristan | leeming, but the /data directory is a mount point for the rw tmpfs right ? | 11:25 |
| leeming | yes | 11:25 |
| gtristan | sigh so I think I was derailed: If I want to write a configure extension to package chunks into rpms; where would I start then ? | 11:47 |
| gtristan | In the context of an extension (write or configure or whatever extension)... can I get a dict of all the artifacts ? | 11:47 |
| pedroalvarez | that depends on the metadata you have available in $1/baserock/ | 11:49 |
| gtristan | pedroalvarez, ummm, so if I have a system ? what metadata would I have, the cache keys for each artifact ? would I have a path to the local artifact cache ? | 11:52 |
| gtristan | also ? | 11:52 |
| * gtristan reassembles a system and looks | 11:52 | |
| pedroalvarez | :P | 11:52 |
| gtristan | :-/ | 11:52 |
| pedroalvarez | I'm not sure what ybd puts in there, tbh :/ | 11:53 |
| paulsher1ood | puts in where, sorry? | 11:58 |
| gtristan | So in the baserock/ directory I have all the .meta files for each chunk in the system | 11:58 |
| paulsher1ood | yup | 11:58 |
| gtristan | Those .meta files have a git ref, but not a cache key | 11:58 |
| gtristan | also the directory where to get the artifacts is not in context | 11:59 |
| * gtristan wonders if he could get that too | 11:59 | |
| * gtristan wants a.) a staged system to chroot into b.) a list of all artifacts and their cache keys c.) the cache directory | 12:00 | |
| paulsher1ood | the .meta files *should* contain cache keys then. would be easy to fix | 12:00 |
| gtristan | so just missing the cache directory | 12:01 |
| gtristan | Maybe that could be passed as an argument to the extension somehow ? | 12:02 |
| pedroalvarez | sounds as a massive hack, but from the extensions you have access to any file in the host | 12:02 |
| gtristan | so ybd runs a deployment, and says extensions/package-rpms $1 $2 | 12:02 |
| gtristan | where $1 is a staged sysroot and $2 is the cache dir | 12:02 |
| paulsher1ood | if ybd runs a deployment, it already knows cachekeys for everything and cache dir | 12:03 |
| paulsher1ood | (but the extension doesnn't of course) | 12:03 |
| gtristan | paulsher1ood, right, but I'm trying to avoid adding unwanted features to ybd proper | 12:03 |
| paulsher1ood | ack | 12:03 |
| gtristan | pedroalvarez, so yeah I have *access* to any file on the host... but I dont have access to the exact path where ybd is configured to store artifacts | 12:06 |
| gtristan | hmmm, well; how to elegantly jam this square cube up that round hole :-S | 12:06 |
| *** ctbruce has quit IRC | 12:06 | |
| *** ctbruce has joined #baserock | 12:07 | |
| * gtristan notes that it would be interesting if each rpm he had to produce was an individual build step that occurred post system assembly | 12:08 | |
| gtristan | but that's unlikely to happen without severely changing ybd anyway | 12:08 |
| * gtristan goes to eat food :-S | 12:08 | |
| SotK | gtristan: do you need to deploy a system and obtain rpms for it, or just obtain rpms for it? | 12:10 |
| *** gtristan has quit IRC | 12:14 | |
| *** anahuelamo has quit IRC | 12:43 | |
| *** anahuelamo has joined #baserock | 12:45 | |
| paulsher1ood | SotK: i think he wants to create rpms from chunks, that can be installed in systems | 12:58 |
| * paulsher1ood may be wrong though | 12:58 | |
| SotK | does it have to be a configure extension? | 13:02 |
| SotK | why not just write a script which runs ybd with the config option that makes it spit out just cache keys instead of doing a build, and then uses that list of cache keys to get the relevant chunk artifacts and turn them into rpms? | 13:02 |
| paulsher1ood | i think it's more a deployment extension... but can't remember whether those can apply for chunks or not | 13:02 |
| pedroalvarez | the tool to turn them into rpms is inside the system being deployed | 13:03 |
| SotK | ah, I see | 13:04 |
| * paulsher1ood is unsure why that would be the case | 13:04 | |
| paulsher1ood | but maybe it is | 13:04 |
| *** toscalix has quit IRC | 13:36 | |
| *** toscalix has joined #baserock | 13:40 | |
| *** gtristan has joined #baserock | 13:44 | |
| leeming | (x-posting: sorry but this is really blocking me) I have been staring at this for so long now, I really don't know what to try next... if anyone has experience with linux mounts/ bubblewrap, I appreciate any pointers http://stackoverflow.com/questions/39726445/sandbox-mounting-confusion | 13:51 |
| richard_maw | leeming: doesn't `--tmpfs` mount a new tmpfs at /data when the command is run? | 13:56 |
| leeming | yes | 13:56 |
| richard_maw | I'm confused about the complaint that "however, is the /data directory is totally empty (other than the output of my 'touch /data/testwrite'). Note the original /data partition I wanted to mount, actually contains files. | 13:56 |
| leeming | i need /data to be writable, as per the test.. but i also need it to be the original /data | 13:57 |
| richard_maw | I'm not sure I follow, you need a mutable copy of /data for the test? | 13:57 |
| richard_maw | if --tmpfs does that then it's doing more magic than I thought it would | 13:58 |
| leeming | even though it is defined in the root partition | 13:59 |
| leeming | (where did my previous comment go>) | 13:59 |
| leeming | /data needs to be writeable, but it is also defined in the test logic to mount as a tmpfs | 13:59 |
| leeming | ah | 13:59 |
| richard_maw | --tmpfs mounts a new empty tmpfs on top of the /data directory, which hides the files that were in the partition underneath | 14:00 |
| leeming | so i do need to do some fancy shifting of the data? | 14:01 |
| leeming | I can't see/understand how the linux_user_choot code manages that | 14:02 |
| richard_maw | yeah, unless bwrap has a way to make an ephemeral copy of a directory natively | 14:02 |
| leeming | so.. is the test wrong? im lost | 14:03 |
| richard_maw | I'm missing all context for what this is for. the morph and ybd code I recall didn't need to do that, they did staging areas by creating a hard-link tree and marking subtrees as read-only and copying in a build tree and an install path | 14:04 |
| richard_maw | the deploy code made a copy without hardlinks, so it was safe to leave bits writable | 14:05 |
| leeming | no idea,,, it is in the test cases for sandboxlib | 14:05 |
| richard_maw | can you post a link to it? | 14:05 |
| leeming | https://github.com/CodethinkLabs/sandboxlib | 14:05 |
| richard_maw | I meant the test in question, but I can browse | 14:05 |
| leeming | https://github.com/CodethinkLabs/sandboxlib/blob/master/tests/test_all.py#L182 | 14:06 |
| richard_maw | ta | 14:06 |
| leeming | the bit that creates the root-fs is : https://github.com/CodethinkLabs/sandboxlib/blob/master/tests/test_all.py#L107 | 14:07 |
| leeming | just doesn't make sense why it would be part of the root-fs, yet be stated as an extra mount | 14:07 |
| richard_maw | yeah, I don't get the reason for the extra mount either | 14:09 |
| richard_maw | or how it apparently used to work | 14:09 |
| * leeming wonders if he should just totally fudge the test or not then | 14:16 | |
| richard_maw | looks like the linux-user-chroot code would create parameters for making paths read-only, then a writable bind-mount for a temporary directory into the target path, perhaps linux-user-chroot would process those arguments in a different order | 14:16 |
| richard_maw | I'd remove the extra tmpfs mount, I can't see the need for it | 14:17 |
| leeming | ok | 14:18 |
| locallycompact | paulsher1ood, ok, I have something reasonably coherent, could you help me wedge it into ybd? | 14:19 |
| *** gtristan has quit IRC | 14:40 | |
| *** persia__ has quit IRC | 15:01 | |
| *** persia has joined #baserock | 15:04 | |
| locallycompact | leeming, https://gitlab.com/baserock/defslib | 15:19 |
| locallycompact | so this gets as far as resolving the assemblage, calculating cache keys and flattening the assemblage so it's just a one level deep list of chunks with large build-depends lists | 15:21 |
| leeming | so re how ybd sandboxes. it uses the sandboxlib api, which is essentially "degrade_config_for_capabilities" and "run_sandbox" | 15:22 |
| leeming | I assume dn['sandbox'] is the path to the sandbox root-filesystem | 15:23 |
| locallycompact | if we can pull sandboxing into the library, then the assembly code should be much clearer and shorter than what's currently in ybd | 15:23 |
| locallycompact | that seems like a strange field ot mutate the definition with | 15:23 |
| locallycompact | why does that persist | 15:23 |
| *** anahuelamo has quit IRC | 15:23 | |
| leeming | sorry.. are we mixing each other up? | 15:24 |
| *** anahuelamo has joined #baserock | 15:24 | |
| locallycompact | what does that mean | 15:25 |
| leeming | sandboxlib currently has 3 (well 2 in the live version) 'executors'. "degrade_config_for_capabilities" basically picks the best executor, given some config requirements (see sandbox.py::run_sandboxed() for an example) .. | 15:26 |
| leeming | looks like ybd just passes 'sh -c -e [command]' to the sandbox | 15:29 |
| richard_maw | `sh -e -c` command surely? | 15:34 |
| *** faybrocklebank has quit IRC | 15:35 | |
| leeming | nope | 15:35 |
| leeming | argv = ['sh', '-c', '-e', command] | 15:35 |
| richard_maw | eww, sh's command parsing is non-standard then, usually you'd interpret -c as an option that takes a parameter, so it should take its parameter from the next argument | 15:39 |
| paulsher1ood | locallycompact: would love to help, but the next few days are going to be difficult | 15:50 |
| paulsher1ood | leeming: do you know enough of ybd to assist? | 15:50 |
| *** ctbruce has quit IRC | 15:52 | |
| * paulsher1ood believes, but can't prove, that either ybd re-uses morhp code, or someone else frabbed the commandline when introducing sandboxlib | 15:52 | |
| paulsher1ood | in other words, it's not me :) | 15:52 |
| * leeming isn't sure if he has satisfied locallycompact 's question | 15:53 | |
| locallycompact | I do see what it's doing, ish | 15:55 |
| leeming | it basically gets a pointer/ref to the sandbox wrapper in sandboxlib, so {chroot, linux-user-chroot, bwrap} | 15:59 |
| leeming | they all have the run_sandbox method | 15:59 |
| * paulsher1ood looks at defslib, sees 'MorphologyResolver' and 'Actuator' and wonders if there aren't simpler words than those | 16:19 | |
| leeming | MorphResolver is simpler, but I think it would raise an eyebrow | 16:20 |
| rdale | anything with 'Morph' in it is confusing | 16:20 |
| leeming | better than naming it 'def' imo | 16:20 |
| leeming | although naming.. yes.. | 16:21 |
| leeming | but maintaining consistency with prior tooling is another thing to consider, no? | 16:21 |
| locallycompact | the point of actuator is that it's effective, it accepts a dictionary of "places things should go", and some aliases, and a tree server. Ideally I'd like that to be all it should need to build an assemblage with filesystem effects. | 16:22 |
| leeming | what is meant by "assemblage" and "filesystem effects" in this context? | 16:23 |
| locallycompact | assemblage is the new data type, it replaces system and stratum | 16:24 |
| leeming | some collection then? | 16:24 |
| locallycompact | nominally yes | 16:24 |
| locallycompact | it's defined here https://gitlab.com/baserock/spec/blob/lc/010/schemas/assemblage.json-schema | 16:25 |
| locallycompact | by filesystem effects I mean actual affects that affect the filesystem via IO | 16:26 |
| locallycompact | Haskell would make that distinction by type at compile time so I make the distinction as best as possible in python with documentation | 16:26 |
| leeming | "actual affects that affect the filesystem" | 16:27 |
| locallycompact | *effects | 16:27 |
| leeming | ok, but that doesn't make it clearly for me. but nvm | 16:28 |
| locallycompact | The class will actually try and do things outside of program memory | 16:29 |
| leeming | oh sorry, so just simply IO | 16:30 |
| leeming | i thought you were defining a new keyword | 16:31 |
| leeming | also, note the time... and my brain has not worked properly for weeks | 16:31 |
| paulsher1ood | leeming: shame. does your employer know? :) | 16:32 |
| rdale | what is the difference between an 'assembly' and an 'assemblage'? | 16:32 |
| leeming | paulsher1ood, well my failures are recorded :) | 16:33 |
| *** jjardon has quit IRC | 16:36 | |
| *** lachlanmackenzie has quit IRC | 16:37 | |
| *** radiofree has quit IRC | 16:37 | |
| *** rjek has quit IRC | 16:37 | |
| *** zoli_ has quit IRC | 16:37 | |
| *** toscalix_ has joined #baserock | 16:37 | |
| *** CTtpollard has quit IRC | 16:37 | |
| *** locallycompact has quit IRC | 16:37 | |
| *** rdale has quit IRC | 16:37 | |
| *** anahuelamo has quit IRC | 16:37 | |
| *** vgrade_ has quit IRC | 16:37 | |
| *** rjek has joined #baserock | 16:37 | |
| *** perryl has quit IRC | 16:37 | |
| *** lachlanmackenzie has joined #baserock | 16:37 | |
| *** perryl has joined #baserock | 16:37 | |
| *** anahuelamo_ has joined #baserock | 16:38 | |
| *** bfletcher has quit IRC | 16:38 | |
| *** toscalix has quit IRC | 16:38 | |
| *** vgrade has joined #baserock | 16:38 | |
| *** radiofree has joined #baserock | 16:39 | |
| *** rdale has joined #baserock | 16:40 | |
| *** franred has quit IRC | 16:43 | |
| *** cyndis has quit IRC | 16:46 | |
| *** toscalix has joined #baserock | 16:46 | |
| *** lachlanmackenzie has quit IRC | 16:47 | |
| *** jjardon_matrix has quit IRC | 16:47 | |
| *** paulsher1ood has quit IRC | 16:47 | |
| *** toscalix_ has quit IRC | 16:47 | |
| *** paulsherwood has joined #baserock | 16:47 | |
| *** anahuelamo__ has joined #baserock | 16:47 | |
| *** vgrade has quit IRC | 16:47 | |
| *** JPohlmann has quit IRC | 16:47 | |
| *** vgrade has joined #baserock | 16:47 | |
| *** Lachlan1975 has joined #baserock | 16:48 | |
| *** anahuelamo_ has quit IRC | 16:48 | |
| *** franred has joined #baserock | 16:48 | |
| *** CTtpollard has joined #baserock | 16:49 | |
| *** locallycompact has joined #baserock | 16:53 | |
| *** JPohlmann has joined #baserock | 16:55 | |
| *** JPohlmann has joined #baserock | 16:55 | |
| *** bfletcher has joined #baserock | 16:55 | |
| *** cyndis has joined #baserock | 17:00 | |
| *** jjardon has joined #baserock | 17:00 | |
| *** toscalix has quit IRC | 17:11 | |
| *** jjardon has quit IRC | 17:11 | |
| *** bfletcher has quit IRC | 17:11 | |
| *** locallycompact has quit IRC | 17:11 | |
| *** toscalix has joined #baserock | 17:11 | |
| *** franred has quit IRC | 17:11 | |
| *** anahuelamo__ has quit IRC | 17:12 | |
| *** anahuelamo__ has joined #baserock | 17:12 | |
| *** CTtpollard has quit IRC | 17:12 | |
| *** lc_ has joined #baserock | 17:12 | |
| *** franred_ has joined #baserock | 17:12 | |
| *** CTtpollard has joined #baserock | 17:13 | |
| *** tiagogomes has quit IRC | 17:21 | |
| *** lachlanmackenzie has joined #baserock | 17:22 | |
| *** lc__ has joined #baserock | 17:22 | |
| *** Lachlan1975 has quit IRC | 17:22 | |
| *** CTtpollard has quit IRC | 17:22 | |
| *** lc_ has quit IRC | 17:22 | |
| *** tiagogomes has joined #baserock | 17:24 | |
| *** CTtpollard has joined #baserock | 17:24 | |
| *** lc__ has quit IRC | 17:32 | |
| *** jjardon has joined #baserock | 17:37 | |
| *** bfletcher has joined #baserock | 17:54 | |
| *** rdale has quit IRC | 18:03 | |
| *** lachlanmackenzie has quit IRC | 18:10 | |
| *** lachlanmackenzie has joined #baserock | 18:10 | |
| *** bfletcher has quit IRC | 18:11 | |
| *** zoli_ has joined #baserock | 18:38 | |
| *** bfletcher has joined #baserock | 18:40 | |
| *** toscalix has quit IRC | 18:45 | |
| *** gtristan has joined #baserock | 19:23 | |
| *** jjardon has quit IRC | 19:26 | |
| *** lachlanmackenzie has quit IRC | 19:27 | |
| *** bfletcher has quit IRC | 19:27 | |
| *** gtristan has quit IRC | 19:27 | |
| *** lachlanmackenzie has joined #baserock | 19:29 | |
| *** _longines has quit IRC | 19:34 | |
| *** juergbi has quit IRC | 19:34 | |
| *** SotK has quit IRC | 19:34 | |
| *** richard_maw has quit IRC | 19:34 | |
| *** leeming has quit IRC | 19:35 | |
| *** bjdooks has quit IRC | 19:35 | |
| *** _longines has joined #baserock | 19:35 | |
| *** leeming has joined #baserock | 19:36 | |
| *** lachlanmackenzie has quit IRC | 19:36 | |
| *** SotK has joined #baserock | 19:37 | |
| *** SotK has quit IRC | 19:37 | |
| *** SotK has joined #baserock | 19:38 | |
| *** lachlanmackenzie has joined #baserock | 19:38 | |
| *** juergbi has joined #baserock | 19:38 | |
| *** gtristan has joined #baserock | 19:39 | |
| *** bjdooks has joined #baserock | 19:45 | |
| *** bfletcher has joined #baserock | 19:49 | |
| *** richard_maw has joined #baserock | 19:53 | |
| *** ChanServ sets mode: +v richard_maw | 19:53 | |
| *** jjardon has joined #baserock | 19:57 | |
| *** jjardon has quit IRC | 20:22 | |
| *** bfletcher has quit IRC | 20:23 | |
| *** juergbi has quit IRC | 20:24 | |
| *** juergbi has joined #baserock | 20:24 | |
| *** bfletcher has joined #baserock | 20:35 | |
| *** jjardon has joined #baserock | 20:43 | |
| *** juergbi` has joined #baserock | 20:44 | |
| *** juergbi has quit IRC | 20:45 | |
| *** bfletcher has quit IRC | 20:45 | |
| *** gtristan has quit IRC | 20:58 | |
| *** cosm has quit IRC | 21:04 | |
| *** trn has left #baserock | 21:51 | |
| *** bfletcher has joined #baserock | 21:58 | |
| *** vgrade has quit IRC | 22:50 | |
| *** vgrade has joined #baserock | 22:50 | |
| *** JPohlmann has quit IRC | 22:51 | |
| *** JPohlmann has joined #baserock | 22:53 | |
| *** jjardon_matrix has joined #baserock | 23:02 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!