| radiofree | It should work paulsher1ood | 00:23 |
|---|---|---|
| radiofree | I know that place and I know they have guest wifi | 00:23 |
| radiofree | But yes deploy is broke. I'll submit a bug report tomorrow | 00:23 |
| radiofree | Build with no git update works fine. It is just deploy | 00:24 |
| radiofree | Binutils every time | 00:24 |
| * persia is reading backscroll and fails to understand how copying scripts from a wiki page could possibly be easier than `git clone ${MAGIC_REPO}; cd baserock_vagrant; vagrant up` | 08:37 | |
| petefoth | persia: if you are in a browser, viewing the script, you can press a single down;oad button. No need to swithc to a terminal, and git cline. And why would siomebidy who wants to run a creipt to setup VirtualBox or KVM want to use Vagreant? | 08:39 |
| *** locallycompact [~lc@110.154.199.146.dyn.plus.net] has joined #baserock | 08:40 | |
| persia | petefoth: I generally only want to read scripts when either I expect I can't trust them or something has gone wrong. | 08:40 |
| persia | Also, I don't think most new users *care* whether they are using one or another virtualisation technique: they haven't been using Baserock enough to develop a preference. | 08:40 |
| petefoth | persia: then don’t bother reading it - just clone (or download) it and run it :) | 08:41 |
| persia | However, my estimation of people can be wrong, and my attitude towards scripts may be different (plus, my opinions about the low quality of cut&paste on the linux desktop may not be shared) | 08:41 |
| persia | But if it is a script on a wiki page, I *can't* clone/download and run it! | 08:42 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:43 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 08:43 | |
| persia | petefoth: As I read backscroll more, I discover you've already made this point :) | 08:43 |
| petefoth | I don’t have neartly enough data to make judgements on what “most” people want, need or care about. If we knew *most* people wanted to work with e.g VBox (perhaps because they already use it) then we needn’t bother with explingin how to set up KVM. So we make some educate guess, act according to those guesse and. if we have the time, try to establish alter on which guesse were correct | 08:44 |
| petefoth | persia: ‘Read first, ask questions later”? Where’s the fun in that ;) | 08:45 |
| persia | Oh, yes, I agree that documenting both is useful. I just had instinctive horror at someone's claim that "scripts would be simpler [than vagrant]" | 08:46 |
| petefoth | persia: That wasn’t me (I think / hope) | 08:47 |
| persia | petefoth: Indeed, it was not :) | 08:48 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:59 | |
| pedroalvarez | so, when deploying we need network to figure out what artifact we are going to deploy... I was wondering if it would be still needed now that we have in definitions: a) all the chunk morphologies and b) the sha1s and repos of all the chunks. Is anything else needed to construct the cachekey of a system artifact? | 09:11 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:17 | |
| persia | For optimisation reasons, we need the tree SHA for the chunk refs, which may not be local | 09:21 |
| paulsher1ood | build has already done the mappings. it could trivially leave that work in place for potential deploys | 09:23 |
| paulsher1ood | ? | 09:23 |
| radiofree | everything else seems to be fine, without the network | 09:23 |
| persia | I'm not sure it's trivial, but yes, caching the cache-key mappings should address this | 09:24 |
| radiofree | it always seems to halt at binutils though | 09:24 |
| pedroalvarez | radiofree: isn't binutils the first thing we build? | 09:24 |
| radiofree | ..ah | 09:25 |
| radiofree | paulsher1ood: you can do the demo, just connect to a phone for the deploy | 09:26 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:27 | |
| Mode #baserock +v ssam2 by ChanServ | 09:27 | |
| paulsher1ood | radiofree: yup thanks | 09:28 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:30 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:57 | |
| ssam2 | hooray for write extension documentation! thanks petefoth! | 09:57 |
| petefoth | ssam2: we aim to please ;) | 09:58 |
| ssam2 | a lot of patch series in my email catchup that have already been reviewed and merged, in fact! which is a nice start to the day! | 10:01 |
| straycat | my build failed | 10:02 |
| * straycat restores balance | 10:02 | |
| straycat | and not in the way i expected :( | 10:02 |
| radiofree | pedroalvarez: have you seen [PATCH 0/2] V2: Add generic weston systems (x86 and ARM) to ci server? | 10:29 |
| pedroalvarez | radiofree: looks ok, but do we want it to make it a first class system? Shouldn't we add other systems we care more about (like the genivi one) first? | 10:31 |
| radiofree | pedroalvarez: would it mean cache.br would have cache for mesa etc? | 10:33 |
| radiofree | pedroalvarez: i think the weston system is fundamentally the same as a genivi system | 10:33 |
| radiofree | weston/wayland-ivi-extension only takes a few minutes to build | 10:33 |
| jjardon | radiofree: https://bugs.freedesktop.org/show_bug.cgi?id=86701 | 10:34 |
| radiofree | :\ | 10:35 |
| radiofree | lol "I'm aware of 2 features that we will lose: | 10:36 |
| radiofree | - swrast on Wayland - I'm not sure about this. Perhaps kms-swrast has | 10:36 |
| radiofree | addressed this already." | 10:36 |
| pedroalvarez | radiofree: I'm just saying that if we are going to increase the feedback time by adding more systems to the CI, I'd like those system to be systems that we really care about. I'm not saying "-1, don't merge it", I'm just waiting others opinion. | 10:38 |
| radiofree | personally i care more about upstream weston then i do ivi-shell | 10:39 |
| pedroalvarez | but you have to understand that I care more about ivi-shell one since is the one we have to do releases | 10:39 |
| pedroalvarez | and as you said, weston only takes a few minutes to build :P | 10:40 |
| radiofree | yeah, i also build ivi-extension/weston-ivi-shell constantly, i can be the human CI for that ;) | 10:41 |
| pedroalvarez | :) | 10:41 |
| persia | pedroalvarez: I think the interesting part of "systems we care more about" is the definition of "we". Personally, I'd rather see mesa tested than GENIVI, but that's just me :) | 10:45 |
| persia | (and no reason you can't add GENIVI in a patch as well, if you want CI for it, to ease your release efforts) | 10:46 |
| pedroalvarez | persia: you can +1 it if you want | 10:50 |
| pedroalvarez | certainly I'm starting to think that is a good idea, and also this way we can see how mason behaves when building more than one system | 10:50 |
| persia | I don't know the infrastructure implications, or I would have done so already :) | 10:50 |
| persia | I'm not saying you should +1 it, only that I don't know that it is safe to assert a "we" that cares more about one thing than another. | 10:51 |
| persia | Or at least, without specifying the "we". For "we" meaning "the release team", I'm sure your statement is accurate :) | 10:51 |
| pedroalvarez | I'm saying "we" because I want a consensus about what we care more about | 10:52 |
| pedroalvarez | I'm not asserting that we care more about the genivi system than the stock-weston one | 10:52 |
| radiofree | the weston system is actually the genivi system | 10:54 |
| radiofree | only difference is the version of weston, so it will build the genivi system as well | 10:54 |
| radiofree | it's also, IMO, more appealing to outsiders not interested in cars | 10:54 |
| radiofree | we're stuck at... 1.4.9x of weston with ivi-shell | 10:54 |
| radiofree | although patches have just landed to merge for 1.7.0 | 10:55 |
| pedroalvarez | all right, let's add it to the CI and see how it goes. | 10:56 |
| radiofree | yay :D | 10:57 |
| pedroalvarez | I think I'm the only one who cares about genivi :) | 10:57 |
| persia | I thought there were other folk on the release team: at least other folk *used* to do releases once in a while. | 11:00 |
| * persia doesn't really understand the release team organisation very well, but is happy in ignorance, as this leaves less emotional attachment to the release concept | 11:00 | |
| petefoth | Yesterday straycat reminded me that ‘any of the env vars can be passed on the command line to morph deploy’. I just want to double check that this is true for the OPENSTACK_* parameters in the OpenStack write extension | 11:03 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 11:03 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 11:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 11:03 | |
| petefoth | pedroalvarez: SotK: jmacs: ^^ | 11:03 |
| jmacs | I know nothing about Openstack | 11:03 |
| SotK | it is true | 11:03 |
| petefoth | jmacs: sorry to have bothered you then :) SotK: thanks | 11:04 |
| SotK | we advise passing OPENSTACK_PASSWORD on the command line iirc | 11:04 |
| franred | petefoth, you can do it | 11:04 |
| persia | I remember having some discussion about this on the mailing list. There is apparently a partial conversion between some entries on the command line and differing values for reasons I never understood. | 11:04 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 11:04 | |
| petefoth | franred: thanks | 11:04 |
| persia | So `OS_PASSWORD=mypass morph deploy ....` has a similar meaning to `morph deploy ... OPENSTACK_PASSWORD=mypass`, and it isn't permissible to swap the all-caps entries (despite differing names). | 11:05 |
| persia | I believe the one *after* `morph` overrides the one before, but with the abovementioned name mangling. | 11:06 |
| persia | That all said, one probably should not use OPENSTACK_PASSWORD as a parameter | 11:06 |
| persia | Rather, one should exchange a password with Keystone to get a token, and then pass the token as a parameter | 11:06 |
| petefoth | persia: eeeeeew! That’s not very nice :) | 11:07 |
| franred | persia, that remains to the user who do the cluster morphology | 11:07 |
| petefoth | persia: maybe, but unless that’s how it currently works I’m not going to document it that way | 11:07 |
| persia | (using the password on the command line is a fallback, because when there is no token, e.g. glance client will query keystone to get one) | 11:07 |
| persia | petefoth: That is how it currently works | 11:07 |
| petefoth | persia: OK, then I can add some words to the docs - thanks | 11:08 |
| persia | franred: Yes, but we should probably document the best practice, rather than the known insecure one | 11:08 |
| petefoth | persia: I think we should provide full and accurate documentation, with appopriate recmmendations | 11:09 |
| franred | persia, I though you need user-password for keystone give you the token, so all the other services/clients will know that you are logged | 11:09 |
| franred | s/give/giving/ | 11:09 |
| franred | so you also do not need the token (not sure, but I think adding the token to the parameters is getting deprecated as far as I can see in the messages from keystone.middleware) but I can be wrong | 11:11 |
| SotK | has someone made sure that `OS_PASSWORD=foo morph deploy...` works before we document doing it that way? | 11:12 |
| persia | petefoth: I can agree with that. Note that 99% of OpenStack users just copy the rcfile from Horizon into their environment, so are entirely unaware of the authentication model (and would not use any of these in either the command line or the cluster morphology) | 11:12 |
| * SotK would expect morph to complain about OPENSTACK_PASSWORD not being provided | 11:12 | |
| persia | franred: All services *except* Keystone require a token for authentication | 11:13 |
| pedroalvarez | SotK: true! | 11:13 |
| persia | SotK: I think we quelled that spurious error. If not, we ought. | 11:13 |
| SotK | yes, openstack.check still raises cliapp.AppException if any of the OPENSTACK_* variables are not present | 11:14 |
| petefoth | I think the approach we should take is that I will documnent what currentlky happens (and hopefully works). IF we then decide we need to change, we can work on a patch which moodifies the impelmentation *and* the docs at the same time | 11:14 |
| SotK | petefoth: +1 | 11:14 |
| pedroalvarez | makes sense to me | 11:15 |
| franred | persia, I will have a look at it once again | 11:15 |
| persia | petefoth: Heh. OK. If our practices happen to be so deviant from normal, then I agree you should document baserock practices, rather than typical OpenStack practices (but this probably represents a bug) | 11:18 |
| SotK | a simple fix would be to call the variables OS_* rather than OPENSTACK_*? | 11:18 |
| SotK | that way both workflows will allow a successful deployment | 11:19 |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [] | 11:19 | |
| * SotK wonders why they weren't called that in the first place | 11:19 | |
| petefoth | I like the idea of ‘moodifying’ our SW - turning it into a teenager prone to sulks and sullen unco-operativeness :) | 11:20 |
| persia | In the thread where this was discussed a while back, it was to distinguish the morph configuration variable names from the environment variable names, which was intended to reduce confusion. | 11:20 |
| SotK | it doesn't seem like confusion has been particularly reduced by this | 11:23 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:23 | |
| jjardon | pedroalvarez: radiofree \o/ thanks, this is a HUGE improvement!! | 11:26 |
| petefoth | If anyone is happier reviewing juts the text of virtualbox-ssh.write.help rather than the full patch set, it can be found at http://paste.baserock.org/ilezuloxaq.vhdl | 11:29 |
| richard_maw | petefoth: biff | 11:30 |
| radiofree | jjardon: pedroalvarez reviewed it :\ | 11:31 |
| jjardon | radiofree: yeah, both you and him | 11:32 |
| radiofree | you put richard in the merge though | 11:33 |
| jjardon | about the NETWORK_CONFIG problem: Any opinions about what I suggested yesterday: to pass the configuration directly in the native format, so no script is needed, similar how coreos does: https://coreos.com/docs/cluster-management/setup/network-config-with-networkd/ | 11:34 |
| jjardon | oops, sorry pedroalvarez, richard_maw It will not going to fix it but I will make clear by email who review it | 11:36 |
| radiofree | how come the arm mason stays red for so long? http://mason-armv7lhf.baserock.org/ | 11:37 |
| radiofree | because the changes haven't reached the trove it's using yet? | 11:37 |
| SotK | I think that is the reason | 11:37 |
| radiofree | yes, ERROR: Ref 778f4b6a95dc3510d9d2d70866d5142691da1a78 is an invalid reference for repo git://cache.baserock.org/baserock/baserock/definitions | 11:37 |
| persia | Why does it use a different trove again? | 11:37 |
| radiofree | how come the x86 mason doesn't have that problem? | 11:38 |
| radiofree | http://mason-x86-64.baserock.org/ is a flawless sea of green | 11:38 |
| radiofree | persia: distbuild i think | 11:39 |
| radiofree | needs to push temporary build branches | 11:39 |
| persia | Oh, right. | 11:39 |
| SotK | the arm mason uses the jetson cloud distbuild network, which is using a different trove to the distbuilds that are deployed with the x86 masons AIUI | 11:39 |
| persia | Can that be fixed, or does it break something if fixed? | 11:39 |
| SotK | pedroalvarez knows about this maybe? | 11:39 |
| radiofree | ah, so x86 mason is not a distbuild and uses gbo directly? | 11:39 |
| persia | Wait, right, the x86 distbuilds also do the same thing, so why can't ARM use the same trove? | 11:39 |
| radiofree | persia: might not be distbuilding on x86? | 11:40 |
| radiofree | in which case it can use gbo directly | 11:40 |
| radiofree | maybe mason can force the trove mirror when it sees there's an update to gbo definitions? | 11:41 |
| radiofree | before building | 11:41 |
| pedroalvarez | I'm going to try to explain this | 11:41 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:42 | |
| radiofree | it took 43 minutes between definitions being updated an it working last time! | 11:42 |
| pedroalvarez | x86 mason is also a distbuild network. This distbuild network is using g.b.o directly, because we know that it's always building branches (master) that are already in g.b.o, so this distbuild doesn't need to push temporary branches ever. | 11:43 |
| pedroalvarez | with the jetsons we are using a different trove for the sources, so we can use it to build things that require a temporary build branches, i. e., things that haven't been pushed | 11:44 |
| pedroalvarez | I'll be ok with using g.b.o directly, but I don't know all the implications | 11:45 |
| pedroalvarez | radiofree: yeah, it can take 2 hours | 11:46 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 11:46 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:46 | |
| radiofree | ah | 12:07 |
| radiofree | we need two jetson distbuild networks then! | 12:07 |
| pedroalvarez | haha | 12:07 |
| radiofree | one for mason (uses gbo) and another one for doing test builds! | 12:07 |
| pedroalvarez | note that I'm of the opinion that we could use g.b.o also for test builds | 12:08 |
| persia | I'd rather not clutter those repos, because the build commits make my visualisation tools unhappy. | 12:09 |
| persia | Is there a way to cause distbuild not to push temporaries, if it is only building known commits? | 12:10 |
| persia | (and to force folk to only distbuild things available from a public git server)? | 12:10 |
| pedroalvarez | iirc it doesn't push anything that is already in the trove | 12:10 |
| pedroalvarez | ah, you mean to not push temporary branches ever? I don't know :/ | 12:11 |
| persia | Or is it possible to have the target configurable on a per-run basis, so that random people distbuilding on the internet get sent to one place, and those who pass some magic authentication token can (avoid) pushing to g.b.o? | 12:11 |
| persia | I'd be very happy with "never push any temporary branches", but it means that folk always have to push stuff before distbuilding, which breaks some workflows. | 12:12 |
| persia | (or it requires a new and different distbuild) | 12:12 |
| radiofree | could you not just push the branches to the controller? | 12:13 |
| pedroalvarez | radiofree: all the workers need the branches, not just the controller | 12:14 |
| persia | That requires modifications to distbuild | 12:14 |
| radiofree | pedroalvarez: yeah | 12:14 |
| radiofree | rather then git clone TROVE_HOST/my-temp-build-branch it'd be git clone CONTROLLER/my-temp-build-branch | 12:14 |
| persia | Perhaps we could just not give any of the workers or the controller keys that have write access to g.b.o? | 12:14 |
| persia | So if they try to write, it fails, and it all falls down, but if the commit is already present, everything works? | 12:14 |
| radiofree | people would get mad | 12:15 |
| pedroalvarez | hm.. I think that the initiator would be the one that pushes to g.b.o, not the controller | 12:15 |
| radiofree | although if you made the error message clear (would be novel for distbuild) it might be ok | 12:16 |
| radiofree | "YOU HAVE TO PUSH THIS SOMEWHERE IF YOU WANT TO DISTBUILD IT" | 12:16 |
| persia | Sadly, the configuration is such that the value of SOMEWHERE happens to be defined in the distbuild network configuration, rather than the caller configuration. | 12:19 |
| persia | As a result, one ends up telling users "NO PONY FOR YOU", rather than "GO DO THIS SENSIBLE THING" | 12:20 |
| * radiofree hopes paulsher1ood didn't forget the psu for his jetson | 12:24 | |
| radiofree | would that work though, having the controller act as the temporary git server? | 12:27 |
| radiofree | obviously need some changes, but would be equivalent right? | 12:27 |
| pedroalvarez | radiofree: then you have to have push access to the controller git server | 12:28 |
| radiofree | don't the workers already have that? | 12:29 |
| radiofree | oh right i see what you mean | 12:29 |
| pedroalvarez | I don't know all the implementation details of distbuild though | 12:29 |
| radiofree | well it's the controller that pushes the temp build branches right? | 12:29 |
| pedroalvarez | I think that is the initiator | 12:30 |
| persia | I think that someone should dit down and draw up the architecture, and we should debate it again. | 12:32 |
| pedroalvarez | I agree | 12:32 |
| persia | This many confused folk means that something is conceptually wrong | 12:32 |
| pedroalvarez | here we go! A greener than green feedback! http://mason-armv7lhf.baserock.org/ | 12:33 |
| radiofree | and maybe look at distcc again? | 12:34 |
| *** locallycompact [~lc@110.154.199.146.dyn.plus.net] has quit [Ping timeout: 256 seconds] | 12:34 | |
| persia | radiofree: distcc doesn't solve the same class of problem, but perhaps can be part of a solution. | 12:35 |
| radiofree | certainly for things like Qt it would be really nice | 12:35 |
| radiofree | "we're not using any other workers because we're waiting for this to be built first... distcc it" | 12:37 |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 12:49 | |
| straycat | sup | 12:49 |
| straycat | franred, I think your build will be fine | 12:49 |
| Kinnison | radiofree: distcc is difficult unless you can build into the definitions an understanding of when it becomes available | 12:49 |
| petefoth | the file morph/morphlib/plugins deploy_plugin.py mentions 5 values for type: tar, rawdisk, virtualbox-ssh, kvm and nfsboot. I suspect we need to add ‘openstack’ as a type. Can anyone offer some words to complete the following sentence ‘* `openstack` where Morph…’? | 12:49 |
| Kinnison | radiofree: and of course, the distributed build stuff then needs to be able to construct appropriate system roots | 12:50 |
| franred | straycat, you mean with the change on setup_tools? | 12:50 |
| * petefoth know sqrt(very_little) about OpenStacck | 12:50 | |
| pedroalvarez | petefoth: there are even more values now | 12:50 |
| straycat | franred, yesh the problem seems to be that for whatever reasons pbr with setuptools fails to obtain the dependencies it needs: it doesn't have pbr so it can't process itself. | 12:51 |
| radiofree | Kinnison: could you recreate the same build root on each worker, then run the distcc server in the chroot? | 12:51 |
| straycat | If I install keystone's dependencies myself (using pip install) then the problem goes away. | 12:51 |
| petefoth | pedroalvarez: why doesn’t that surprise me? :) | 12:51 |
| straycat | This also explains why the morph build I ran didn't fail, because the morph build already has all the dependencies | 12:51 |
| Kinnison | radiofree: You could, but it'd need to be a conscious effort to donate that worker's time to that particular build, because building up/tearing down those would be more expensive than you'd like if you wanted to do it more than once during a build cycle | 12:51 |
| petefoth | ‘Documentation out of step with the code: shock!’ | 12:52 |
| franred | straycat, that also explain why I can not remove pip or pbr from my strata | 12:52 |
| petefoth | pedroalvarez: so ssh-rsync and initramfs are the oither missing types? | 12:53 |
| robtaylor | Kinnison: ah, turns out ix.io is by the same guy as sprunge.us | 12:53 |
| radiofree | Kinnison: good point, for most things the current setup is fine, maybe there could be something in the chunk to say "distcc" this | 12:53 |
| petefoth | Any others? | 12:53 |
| radiofree | it would have a massive benefit for the really big stuff, like qtbase | 12:54 |
| pedroalvarez | image-package.write pxeboot.write sdk.write | 12:54 |
| pedroalvarez | they are in definitions.git. not sure if we should document them as well | 12:54 |
| petefoth | pedroalvarez: they don’t have their own write extennsions in morph though? | 12:56 |
| pedroalvarez | this is because morph deploy can use write extensions from morph.git and from definitions.git (or in whatever repo your definitons are) | 12:57 |
| petefoth | pedroalvarez: OK. I may neeed to split my ‘Documentation for write extensions’ task up a bit further then | 13:00 |
| petefoth | Actually, there’s a good help file for pxeboot.write which could maybe do with formatting to match the others, but I guess that is low priorrity. And image-package.write has lots of help in comments which I can easily move to a write.help | 13:04 |
| petefoth | I could still dop with some words about openstack deployment type though, as in my original question: “Can anyone offer some words to complete the following sentence ‘* `openstack` where Morph…’?” | 13:05 |
| pedroalvarez | petefoth: can you give me an example with kvm and I'll try to make the openstack one? | 13:08 |
| petefoth | pedroalvarez: vbssh is ‘“`virtualbox-ssh` where Morph creates a VirtualBox disk image, and creates a new virtual machine on a remote host, accessed over ssh.” and kvm is “’`kvm`, which is similar to `virtualbox-ssh`, but uses libvirt and KVM instead of VirtualBox. “ | 13:10 |
| pedroalvarez | openstack: where Morph creates a raw disk image and deploys it to an OpenStack host using Glance | 13:12 |
| pedroalvarez | s/deploys/uploads/ | 13:13 |
| petefoth | pedroalvarez: perfect - thanks. | 13:14 |
| petefoth | similar words for image-package pxeboot sdk initramfs would be very welcome from anyone who knows anything aboput them | 13:14 |
| petefoth | and ssh-rsync | 13:16 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [] | 13:31 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 13:33 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 13:33 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 13:33 | |
| Kinnison | radiofree: Mmm if a chunk could say "I'm very compile-intensive, it's worth dedicating extra workers to me" that oculd be useful | 13:59 |
| richard_maw | it's be better if we could have a heuristic to determine which builds are likely to be slow, so we should use distcc to parallelise further, rather than using those other nodes for building other chunks in parallel | 14:03 |
| franred | how can I check what I have inside of my system before deploy it? I know that we have a system cache artifact which I can zcat and look for what I want to check if it is inside... but which artifact is my system? | 14:04 |
| pedroalvarez | I normally use tar -tvf ... | 14:05 |
| richard_maw | franred: after you do a build it should list the path to the file | 14:05 |
| richard_maw | if it doesn't, you can try passing --verbose | 14:05 |
| franred | pedroalvarez, richard_maw, cheers | 14:17 |
| straycat | ssam2, hey, would you prefer me to send my import branch for review when i'm ready? | 14:25 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 14:26 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:27 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 14:29 | |
| ssam2 | straycat: It'd be helpful to send for review, I think | 14:30 |
| ssam2 | straycat: although are you on holiday from next week ? if so I guess any comments I have will need to also be fixed up by me as well ;) | 14:31 |
| straycat | yeah i might not be around for a month or so, and i'll be working on other stuff probably | 14:34 |
| ssam2 | ok. not a problem | 14:38 |
| straycat | okay i'll send for review once i've done a bit more testing | 14:49 |
| straycat | if first reviews are quick then i can probably get the fix ups done | 14:50 |
| radiofree | Kinnison: richard_maw: sorry was out at lunch | 14:52 |
| radiofree | some heuristic would be nice, but that sounds scary and complicated compared to a simple marker in the chunk :\ | 14:52 |
| Kinnison | mmm | 14:53 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:53 | |
| franred | where do live the logs for the built chunks? | 14:53 |
| persia | franred: Locally, they are stored in the same cache directory as the artifacts | 14:55 |
| persia | (with a similar name, so if you know the name of the artifact, you can deduce the name of the log) | 14:55 |
| persia | For non-local builds, I have no idea | 14:55 |
| straycat | for non-local builds you get the build logs put in your workspace | 14:56 |
| persia | In the workspace directly? At what location? | 14:57 |
| straycat | your cwd iirc | 14:57 |
| persia | Ah | 14:58 |
| straycat | Or maybe ssam2 changed it to something else, not sure. | 14:58 |
| pedroalvarez | I believe that still is the current behavior | 14:59 |
| ssam2 | I didn't change that | 15:21 |
| straycat | ahh, so the cache is on port 8080 >.> i probably should have realised that sooner <.< | 15:39 |
| straycat | do we have anything on the wiki about that? | 15:40 |
| pedroalvarez | straycat: I believe so | 15:40 |
| straycat | ok cool | 15:40 |
| pedroalvarez | straycat: found it on: http://wiki.baserock.org/quick-start/ | 15:41 |
| pedroalvarez | richard_maw: following your suggestion of using a context manager I've implemented this: http://paste.baserock.org/gujozuqudo.py | 15:44 |
| pedroalvarez | does the latter make more sense than the former? | 15:45 |
| straycat | ahh that's so good | 15:46 |
| richard_maw | how does create_raw_disk_image get the location? | 15:46 |
| pedroalvarez | It opens a file using `with open...` and then writes `'\0's | 15:47 |
| richard_maw | yes, but how does it know where to write it? raw_disk is undefined | 15:48 |
| pedroalvarez | oh yeah, raw_disk should be location | 15:48 |
| richard_maw | btw, the former is better than the latter, since if the former raises an exception too early, location might not be a disk image, so the unlink can fail and trample the useful exception message | 15:48 |
| richard_maw | also, you're supposed to name your context managers so it reads like `with a_created_disk_image(location):`, though we don't usually bother with the a_ | 15:50 |
| pedroalvarez | that is a good tip | 15:51 |
| richard_maw | `with create_diskimage(location):` doesn't read as nicely | 15:51 |
| pedroalvarez | disk_image_created(location) | 15:52 |
| pedroalvarez | disk_image_allocated(location) | 15:52 |
| richard_maw | there's a lot of exceptions to this trend in the python standard library, since a lot of functions have had context managers added afterwards | 15:52 |
| richard_maw | pedroalvarez: those sound like they should return a boolean, but I lack sufficient understanding of the english language to describe why | 15:53 |
| * richard_maw goes to look up the PEP | 15:54 | |
| straycat | because disk image created has a subject and a verb, it's not just an object | 15:56 |
| richard_maw | The tense used in the names of the example contexts is not | 15:58 |
| richard_maw | arbitrary. Past tense ("-ed") is used when the name refers to an | 15:58 |
| richard_maw | action which is done in the __enter__ method and undone in the | 15:58 |
| richard_maw | __exit__ method. Progressive tense ("-ing") is used when the name | 15:58 |
| richard_maw | refers to an action which is to be done in the __exit__ method. | 15:58 |
| richard_maw | https://www.python.org/dev/peps/pep-0343 for the interested | 15:59 |
| pedroalvarez | ok, this is done in the __enter__ but not undone in the __exit__ | 16:00 |
| richard_maw | @contextlib.contextmanager makes everything after the yield part of the __exit__ | 16:01 |
| richard_maw | created_cleaning_up_on_error_disk_image is a bit of a mouthful though, so I'd just stick with created_disk_image | 16:02 |
| pedroalvarez | thanks! | 16:02 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:03 | |
| richard_maw | for the tempfile stuff they have a parameter to specify whether to cleanup on exit, but this is because it serves as both a temporary file, and a file that you are working on, and will move into place later | 16:06 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 16:30 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:39 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 16:57 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 16:58 | |
| * straycat finds one more package that fails to import | 17:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:09 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:10 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:11 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 17:18 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 17:19 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 17:19 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:19 | |
| straycat | Okay well this particular package is using disribute a deprecated setuptools fork, so I guess we shouldn't worry about failing to import packages that are using deprecated stuff | 17:22 |
| straycat | s/distribute/&,/ | 17:23 |
| straycat | Oh wow, finding dependencies here involves compilation, yay | 17:31 |
| straycat | and now instead of a list of dependencies I just have some zombie python processes :/ | 17:40 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:03 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:08 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:16 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 18:18 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:22 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:25 | |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has quit [Ping timeout: 245 seconds] | 20:48 | |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 21:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:33 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:58 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:00 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:02 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:02 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 22:06 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 22:06 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:06 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:09 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 22:18 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 22:18 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:18 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 23:31 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 23:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!