IRC logs for #baserock for Tuesday, 2014-12-09

*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]00:35
*** rdale_ [] has joined #baserock03:31
*** rdale [] has quit [Ping timeout: 256 seconds]03:34
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]04:07
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock07:54
*** wdutch [] has joined #baserock08:27
paulsher1oodjjardon: i hope he means that we'll be starting to address some of
*** mike [] has joined #baserock08:51
mike is now known as Guest4493908:52
* paulsher1ood has a baserock system with systemd, apparently configured network, which can't see the outside world...08:55
paulsher1oodany ideas how to debug this?08:55
persiaI'd start with the output of `ifconfig -a` and `netstat -rn`08:58
persiaThe former will enumerate the devices you have available (and current state), and the latter indicate which devices are attached to which routes.09:00
*** mariaderidder [] has joined #baserock09:00
persiaI suspect that the dhcp client hasn't triggered for your interface09:00
persiaInteresting.  You seem to have two different network interfaces, only one of which is routing.09:07
*** mdunford [] has joined #baserock09:07
persiaDo you know if is in your gateway path to the internet?09:08
persiaIf so, it looks like it *should* work.09:09
persiaTry a ping of to verify.09:09
persiaIf that works, try traceroute to some known external source.09:09
paulsher1oodPING ( 56 data bytes09:10
paulsher1ood64 bytes from seq=0 ttl=64 time=83.075 ms09:10
paulsher1oodtraceroute/ping for external hangs09:10
persiaFor external, did you use a name, or an IP?09:11
persiaTry IP.09:12
persiaIt may be that your name service is broken, rather than your network.09:12
persiaIf this is the case, you can add an entry to /etc/resolv.conf to solve it, but it may be that there's some issue with how the dhcp client is configuring nameservice.09:13
paulsher1oodping works. traceroute hangs09:13
paulsher1oodshould /etc/resolv.conf get populated with something by default?09:14
persiaThat would be a name issue.  `traceroute -n` should work.09:14
persiaYour DHCP server should provide some nameservers09:15
persiaIf it isn't, or your DHCP client is broken, you can fix it by adding one manually09:15
paulsher1oodit is, but the names are down (i expect i originally created this vm somewhere else)09:16
persiae.g. `echo nameserver > /etc/resolv.conf`, if you don't mind telling Google when you do lookups.09:16
paulsher1oodi tell google everything anyway :)09:16
* paulsher1ood had and in /etc/resolv.conf .. can't remember adding them09:18
persiaMight have been your DHCP client in some other environment.09:18
persia(but that wouldn't explain why they weren't updated)09:19
* paulsher1ood assumes that something weird happened on his travels, rather than something weird done by baserock09:19
* SotK misses morph petrify09:20
persiaSotK: Why?09:20
SotKI'm too lazy to find, copy, and paste 20 SHAs when I could just type the short tags and run morph petrify to get the same result09:21
paulsher1oodhas morph petrify actually been removed?09:22
persiaAh, OK.  So it's not actually the petrify/unpetrify behaviour you wanted, but rather you are complaining about the horrid interface for setting values.  I think we ought fix that (but that petrify wasn't how).09:23
SotKpaulsher1ood: yep09:23
persiapaulsher1ood: d63f41dadf5aa96a8d9254d31e92711ee160245e removed it in August09:23
SotKpersia: indeed, I don't care for unpetrify, I just don't like finding SHAs and think a computer should do it for me09:24
persiaAgreed.  I have long wanted a tool that would put the ref for my current HEAD into definitions for a given chunk.09:25
*** tiagogomes [~tiagogome@] has joined #baserock09:27
*** bashrc [] has joined #baserock09:35
*** locallycompact [~lc@] has joined #baserock09:56
*** mdunford [] has quit [Ping timeout: 240 seconds]09:59
*** sam__ [] has quit [Read error: Connection reset by peer]09:59
*** Krin [] has joined #baserock10:06
*** mdunford [] has joined #baserock10:15
*** ssam2 [] has joined #baserock10:21
Mode #baserock +v ssam2 by ChanServ10:21
*** sambishop [] has joined #baserock10:29
Krindoes anyone know a way, after creating a systemd .system file in the baserock build, of allowing systemctl enable "insert system name here" to run before the first boot? or how to achieve a similar effect? i'm simply trying to have a service running on first and subsequent boots 10:38
ssam2'systemctl enable' just creates a symlink10:39
ssam2so you can create the symlink manually10:39
ssam2if you run a 'systemctl enable' command I think it tells you what link it created, so just try it and go from there10:39
ssam2there's no magic at work in the 'enable' command10:40
Krinthanks ssam2 :)10:40
petefothHow long will pastes posted to be kept?10:43
pedroalvarezpetefoth: I think you have to assume that they can dissapear10:43
pedroalvarezor disappear10:44
petefothpedroalvarez: Or both :)  Thanks10:44
pedroalvarezpetefoth: here there is some info:
ssam2the Gerrit system we have in master doesn't build, because it tries to write to /home at system-integration time and fails10:45
ssam2did we deliberately prevent system-integration commands from writing to /home ?10:45
* ssam2 wishes for Richard Maw10:46
petefoth...which says 'Pastes will stay for 30 days from their last view.  They may be removed earlier10:46
petefothand without notice.' Just what I needed to know :)10:46
SotKCan I get a quick review on please?11:29
SotKIts a dependency for turbo-hipster, and it doesn't seem worth sending to the list for one lorry11:30
pedroalvarezSotK: +111:30
franredSotK, +111:31
SotKthanks :)11:31
*** locallycompact [~lc@] has quit [Ping timeout: 272 seconds]11:33
ssam2seems that my problem with Gerrit is not copying the file, but changing the permissions after it has been copied ...11:33
paulsher1oodis it fixable?11:36
persiaCan the permissions be set by using install, rather than cp?11:38
ssam2the permissions are being set using 'install'11:39
ssam2well, attempting to be set11:39
ssam2paulsher1ood: it can certainly be worked around, but it's not clear to me what the best/quickest option will be yet11:39
ssam2install returns: install: can't change ownership of /home/gerrit2/gerrit/gerrit-2.9.war: Operation not permitted11:40
persiaHrm.  Annoying.11:44
franredssam2, have you tried create the folder, copy the file and change owner and permissions? (if we can not change permissions should give us the same error)11:44
ssam2I will try that11:45
ssam2I'm currently trying to reproduce the problem outside Morph, but there is a lot of shell wizardly to disentangle11:45
franredIm adding kernel modules to the x86_64 BSP/linux which are explicit for virtualization purposes like: OPENVSWITCH and relatives or VETH, should I create a BSP for openstack or we are fine to add them to all the Kernel/BSP/platforms?11:46
ssam2I feel it'd be better if you create a separate one for now11:49
ssam2it'd be easier to combine two kernel configs later on, than to separate one massive kernel config11:49
persiaAlso, it means that a lot of the non-virtual stuff can be dropped from the virtualisation kernel.11:49
persiaThat said, I've seen teams with separate configs recombine them because it can be annoying ensure the common configuration choices are consistent.11:50
ssam2I don't like that we have a long, uncommented list of kernel config flags. I'd be happier if there was a way of documenting why different flags where there in the config11:50
paulsher1ood+1 for a separate virtualization kernel, especially if it can include the stuffs for docker11:50
ssam2although as long as changes to the configs have good commit messages, it's not a critical problem11:51
*** locallycompact [] has joined #baserock11:55
paulsher1oodif morph was no longer allowed to re-write definitions wholesale, we could return to having comments :)11:58
Zara_Hi, I'm trying to use the baserock-import tool but I'm getting a 'please pass the name of a rubygem onto the commandline' error; I've been told I need to update the baserock-import tool, and that I should use the 'updating morph' guide as a template, substituting morph for the import tool. I've cloned the baserock-import repo, but that's as far as the guide goes, and the tool still doesn't work for me; do I then need to build something/11:58
Kinnisonpaulsher1ood: if tooling wasn't allowed to re-write definitions, you wouldn't be able to have tools to help you with SHAs etc unless you took them out of the definitions and put them somewhere else11:58
Zara_or something else entirely? :)11:58
ssam2Zara_: replace /usr/bin/baserock-import with a shell script that runs the tool from /src/import11:59
paulsher1oodKinnison: which tools? it seems morph petrify is deprecated?11:59
Zara_ssam2: Ah, ok, thanks :)12:00
Kinnisonpaulsher1ood: Well persia wanted a tool12:00
Kinnisonpaulsher1ood: people seem to want to be able to have names *or* shas, particularly when developing something12:00
Kinnisonpaulsher1ood: which implies wanting help to lock it down when they're done with development12:00
persiaBut I don't want SHAs in the structure YAML anyway :)12:00
ssam2I think taking refs out of definitions is a pretty good idea, having had a while to consider it12:00
persiaI want refs in definitions, but in a different file.12:00
ssam2that's what I meant :)12:01
persiaJust a simple mapping of chunk names to refs.12:01
ssam2in fact, I was going to mention this in my reply to the 'feature wishlist', but I've not had time to finish it off yet12:01
paulsher1oodok provided chunk names are unique12:01
persiaNote that I want *repos* in the chunk names.12:01
persiapaulsher1ood: Your @ patch allows this.12:01
persiaErr, repos in the definitions YAML12:02
ssam2persia: phew12:02
paulsher1oodpersia: agreed, but there's more non-uniques to cleanup12:02
persiaApologies for the confusion :12:02
persiapaulsher1ood: True, but not many, and I think we have consensus that we all want unique.12:02
persiaIf it is still in the factory, then I find it especially odd they can't mix modules, unless they haven't any Keystone modules built and tested.12:03
* persia fails12:03
bashrcI thought repos were defined in morph files already12:04
persiabashrc: They are.  Some of the folk who agree with me about putting refs somewhere else also want to put the repos with the refs.12:05
persiaThe idea being that they fork something ,and then want to track refs in the fork, and only do it in one place.12:05
bashrcpersia: doesn't that just create unnecessary work?12:05
persiaMy opinion is that if they are forking, they probably want to change some things in the chunk definitions anyway, or at least system definitions, so they should indicate where they track when they do this.12:06
paulsher1oodpersia: quite a few...
persiaI believe this would generate a format more amenable to automation of ref tracking, which I think is better, because SHAs are annoying to copy&paste.12:06
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]12:06
persiapaulsher1ood: That's lovely output.  Is the tool that produces it something we could add to a test suite for definitions commits?12:07
* persia is thinking about establishing a rule that no new ones may be created12:07
paulsher1oodit's ybd12:08
paulsher1oodso just a few python scripts, no dependencies12:08
persiaHeh.  But ybd does so much more, making it perhaps overkill for just this.  Still, worth considering.12:09
paulsher1oodi reckon the part that does this output is ~100 lines in total12:13
persiaI may extract it.  Alternately, I may propose a policy that just claims no introducing duplicates without an explicit test script.  But for now, $work :)12:16
rdale_we seem to be optimizing data structures to make them easy for humans to use a python command line tool with, when whatever we do that is going to be hard to use12:19
* persia would prefer to skip the human involvement most of the time12:24
rdale_yes, but it's like giving some a database schema, and saying 'here's psql, get on with it'12:25
bashrcoptimising for readability is better than optimising for efficiency if humans are expected to be doing the maintenance/development12:26
rdale_we shouldn't be working a such a low level, that exactly where the name of a repo is stored actually matters12:27
*** zoli_ [] has joined #baserock12:28
*** zoli_ [] has quit [Changing host]12:28
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock12:28
persiaFor git, I deeply care which repo I'm using.  There isn't a "trunk" that is reliable for anything except github.  One has to choose a repo based on the repo maintainer.12:32
rdale_yes, but being able to see the name of a git repo, isn't the same as needing to know exactly how it is stored in baserock in terms of what attribute of what piece of yaml12:33
persiaNo, but I want to write it down when I describe the components of my system, by hand, so it needs to be in a format that humans can easily write, and computers easily read.12:34
persiaI actively don't want to write down the refs.  I want tooling to either grab those according to some rules (e.g. follow-some branch) or use the commit I just made in some local repo.12:35
persiaSo, to my mind, it makes sense to separate the ref definition from the repo definition.12:35
rdale_i would rather we were discussing a baserock entity model, where 'repo' was one entity and 'chunk' might be another, and just modellig the data structure.12:37
pedroalvarezI'd like to create a repo in g.b.o. I see no policy for this in the wiki. What can I do to achieve this?12:39
paulsher1oodjust go ahead, assuming it's a baserock project - you have the powers12:39
paulsher1ood(ie asssuming it's a baserock:baserock/foo or similar)12:40
pedroalvarezyes, a baserock:baserock/foo repo. I don't have the powers actually.12:41
paulsher1oodwhat would you like it to be called?12:41
* paulsher1ood has/had the powers12:42
paulsher1oodpedroalvarez: shoudl be there now12:44
paulsher1oodare you sure you don't have the powers? 12:44
paulsher1ood(the command was  morph trovectl create baserock/baserock/installer-scripts)12:45
pedroalvarezpaulsher1ood: well, I haven't tried, but I think I have to be in one of the gitano groups to be able to create repos12:46
paulsher1oodi assume you're in baserock-writers12:46
paulsher1oodi think that's all you need (maybe baserock-admins)12:47
*** mdunford [] has quit [Ping timeout: 252 seconds]12:47
paulsher1oodanyways, it's done :)12:48
franredssam2, building gerrit in a VM fails in the same way12:49
pedroalvarezpaulsher1ood: tvm :)12:50
ssam2seems that running system-integration commands inside linux-user-chroot causes 'chown' to no longer work12:52
ssam2I have no idea the best thing to do about this so I'll send a mail to the list and work around the problem12:52
paulsher1oodpersia: (103 lines, excluding header... works on .morph files)13:02
persiapaulsher1ood: heh.  That is indeed small enough to be a useful part of acceptance testing for definitions.  Please consider submitting it to scripts/ :)13:03
paulsher1oodi would prefer if morph could use this logic directly, and output the warnings itself :)13:05
persiaHaving that class of logic in the default build tool would indeed be preferable.13:07
Krincould anyone quickly remind me how to commit and push changes i'v made to baserock strata to their respective branches? i'm sure it was something that i did with morph but i'm drawing a complete blank. or am i going crazy and it was just normal git?13:09
pedroalvarezKrin: it's normal git :)13:09
KinnisonFor stratum changes, it's normal git13:09
Krinwoo! *goes to cause chaos fire and confusion... and hopefully pushes*13:10
*** fay_ [] has quit [Ping timeout: 255 seconds]13:31
*** fay_ [] has joined #baserock13:40
*** mdunford [] has joined #baserock13:51
pedroalvarezmeh, I misunderstood one of Richard Maw's emails and I did the wrong thing. He wanted me to put the script in /usr/lib/baserock-installer/, and I understood that he was suggesting to use usr/lib/installer/baserock-installer. As a consequence I've renamed the script when creating it here:
paulsher1oodradiofree: can we use mainline v3.18 kernel for jetson systems by default now?14:27
radiofreeor maybe...14:30
radiofreecyndis: has the cpufreq stuff made it into 3.18?14:30
cyndiswon't be in 3.19 either14:31
cyndisseems like the tegra clock maintainer has been busy14:31
radiofreeis there anyway of achieve "performance" mode without it?14:31
cyndisi talked with him about it perhaps a week back14:32
radiofreecyndis: ok, thanks for the info :)14:33
cyndishopefully we can get it into 3.20.. :)14:33
radiofreei look forward to it :D14:35
radiofreepaulsher1ood: so no, but we can use 3.18+cpufreq patches on top14:35
paulsher1oodis there a branch on gbo containing (just) the cpufreq14:38
paulsher1oodso would that just be a matter of 'git merge baserock/james/jetson-3.17-rc5-cpufreq' on 3.18?14:39
radiofreewe're not using that 3.17 branch14:39
paulsher1oodi know, i'm just looking for shortest way to get to a tidy solution :)14:40
radiofreegit cherry-pick 548897e193584ebcfb156abb740217f5e4f4ca3^..91d36393893d4dfc83894bff421a81210031aeff 14:41
radiofreeshould do it14:41
franredprobably, create a 3.18 branch and cherrypicked the commits are the cleanest solution (merge things are always dangerous)14:41
radiofree(assuming you're working on the GBO linux branch)14:41
paulsher1oodradiofree: fatal - bad revision14:44
*** Krin [] has quit [Ping timeout: 264 seconds]14:44
radiofreepaulsher1ood: oh dear, i'll take a quick look14:44
radiofreepaulsher1ood: sorry, i buggered up14:48
radiofreegit cherry-pick 7548897e193584ebcfb156abb740217f5e4f4ca3^..91d36393893d4dfc83894bff421a81210031aeff14:48
radiofreeapplies cleanly14:48
* paulsher1ood does that, and submits a patch14:58
paulsher1ood(for v3.18)14:58
radiofreeok i'll test it now before i head off15:00
*** Krin [] has joined #baserock15:14
* SotK moans about projects with tagged releases which don't work15:17
* persia continues to disbelieve expecting upstream to provide useful tags is a worthwhile way to spend time15:24
*** tiagogomes [~tiagogome@] has quit [Read error: Connection reset by peer]15:28
*** tiagogomes [~tiagogome@] has joined #baserock15:28
cyndisthe stable tags work just fine if you're ok with their feature set. granted, getting stuff reviewed is pretty slow, but clearly the other end (downstream-style) is not a good option either.15:29
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]15:29
radiofreepaulsher1ood: works, +115:30
radiofreegood to have a single kernel for all systems as well15:30
cyndisyep. without the upstream project who knows where we'd be :)15:31
persiacyndis: I'm a firm believer in downstream solutions with patches provided upstream.  If everyone waits for upstream, it makes the upstream job *really* hard.  When people demo and test things, it makes it easier for upstreams to be confident in their integration.15:32
persiaMind you, not having the patch submitted upstream is unacceptable behaviour, as is ignoring it if it needs rework.15:33
cyndisyeah, i'm not saying that being fully upstream is a sensible solution, far from it15:33
cyndisthere is clearly a need for both. it's just that they shouldn't be so diverged :)15:34
cyndisbut of course it is a very difficult problem.15:35
persiaOh agreed.  That's one of the reasons I like baserock: when everything is in git, and includes the upstream branches, it is easy to do both sides (like radiofree demonstrated)15:35
persiaWell, at least for git.  When upstream uses non-git, or processes patches in a way that are hard to import, it doesn't work as smoothly.15:36
cyndisyeah, i don't like linux's mailing list patch process at all15:36
persiaI don't mind it that much, but mostly because most people who post patchsets also provide links to their repo hosting that patchset.15:37
persiagit-am is also helpful (unsurprisingly, as it was written for this purpose)15:38
cyndisyeah, but then sometimes they don't, and..15:38
cyndisgit am is sometimes helpful but sometimes not, since you don't know the commit the series was built on15:38
persiaBut if someone has a ML patch submission process that isn't git-am compliant, and everyone is using svn (but only two out of 50 contributors have commit), it gets messier.15:39
persiaTrue on both points :)15:39
cyndisi'd also like to see something that collected all the versions of a series and the comments on them. i guess you could build something on the existing system, even.15:41
persiaThere's been a few attempts to write patch trackers that process mailing lists, but most of them seem to wither over time.15:42
persiaEither the writers discover they cannot cause a project to move to a tracker (e.g. linux), or they succeed, and someone points out how much better the alternate patch trackers are in terms of interface and workflow, plus there's less noise on the mailing list.15:43
cyndisyep. i don't see linux moving anywhere anytime soon, unless linus discovers some great new concept for patch tracking and decides to implement it himself :p15:46
persiaI don't think anything else can work for linux.  There is no meaningful trunk.15:47
persiaWell there's Linus' tree, but that isn't necessarily the right basis or target for anything directly.15:47
persiaMost projects have a canonical repository, which makes them more amenable to patch trackers against that repository.15:48
perrylhow do i implement a cron job on baserock? i want to run a script every five hours, but i don't know how to point to the script in question15:52
persiaIf you have a system with cron installed, I'd suggest adding something to /etc/crontab.15:54
persiaIf you can run as a non-root user, consider using that user's crontab.15:54
pedroalvarezI think that the right way to do this is using a systemd.timer15:54
* persia suspects that to be a cleaner solution, with less extra components15:55
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock15:55
perrylentirely possible; from the looks of it cron is good for a user-specific case, i will look into systemd.timer15:55
pedroalvarezperryl: it's pretty easy. Here there are some examples:
* SotK wonders what the procedure is for updating a tarball lorry?15:58
KinnisonChange the URL15:59
Kinnisonthat should just about be it15:59
persiaDoesn't changing the URL cause the generated repo to gain a commit?15:59
perrylpedroalvarez: am i right in thinking that it would live in root/units for the repo containing the script?16:00
Zara_hm, stuck on the import tutorial at the 'fixing builder' step; I get this error:16:00
Zara_2014-12-09 15:56:52 [Build 163/184] [builder-3.2.2] Extracting file:///src/workspace/baserock/me/import-rails/checkouts/ruby-gems_builder into /src/tmp/staging/tmpn7kTee/builder-3.2.2.build16:00
Zara_ERROR: Failed to copy file:///src/workspace/baserock/me/import-rails/checkouts/ruby-gems_builder into /src/tmp/staging/tmpn7kTee/builder-3.2.2.build16:00
franredI though the new generated repo gain a branch16:01
franredKinnison, persia ^^ ?16:01
Zara_(tried searching the wiki for 'failed to copy file' but no luck)16:01
pedroalvarezperryl: it doesn't have to.16:01
Kinnisonfranred: it gains a tag and a new commit on master16:01
franredoh, ok16:02
SotKcan I get a quick review on please, it seems the version I found on pypi first time didn't work16:02
ssam2SotK: seems fine, +116:06
pedroalvarezSotK: also to me16:06
* paulsher1ood wonders if anyone else would be interested in +1 and merging the 3.18 patch16:06
pedroalvarezI wonder if any particular test should be done, although I've seen a lot of kernel upgrades in baserock that just work16:07
ssam2paulsherwood: I'm in the process of testing it16:07
ssam2(as part of a Gerrit deployment that I was doing anyway)16:07
* paulsher1ood has built and booted it, radiofree has built booted and tested graphics16:08
paulsher1oodooh, cool. did you fix the gerrit issue, ssam2 ?16:08
Zara_can anyone help me with the error I mentioned above?16:09
ssam2paulsher1ood: I will work around the issue that I was discussing here earlier16:10
rjekZara_: How much disc space is there in /src free?16:10
mwilliams_ctZara_: any use? Might be out of disk space16:10
Zara_it's a different error, though that might just mean the message has changed16:10
KinnisonI'd check free space16:10
Kinnisonesp. in your tempdir and cachedir16:11
Zara_Ok, I'll try it out now :) If it works, I'll add that error message to the wiki so it's searchable16:11
paulsher1oodZara_: please paste the result of df somewhere?16:11
persiafranred: As I understand it, the repo matching the lorry name gets a commit matching the tarball contents (which is why the name has to change when we lorry something with a different history)16:11
paulsher1oodZara_: (or even 'df -h')16:12
Zara_paulsher1ood: here, though I'd already followed Kinnison's instructions so I'm not sure how useful it is now:
franredpersia, in this case we don't need to change the name, only the tarball URL, it will be the same git repository for us because we are writing the history16:14
Zara_the command is useful for me to know in the future, though, thanks :)16:14
KinnisonZara_: and your morph.conf has tempdir and cachedir set inside /src ?16:14
Zara_I think so; I configured it according to the wiki instructions16:15
persiafranred: That is my understanding, yes.16:15
KinnisonZara_: check?16:15
rdale_does file:///src/workspace/baserock/me/import-rails/checkouts/ruby-gems_builder contain an actual git repo with builder in it?16:15
Kinnisonpedroalvarez: is it possible to disable paste.b.o's clearly very broken auto-detection of paste content type?16:15
Zara_Kinnison: yup, both in src16:16
KinnisonZara_: most oddness16:16
Zara_I'll try the command now I've cleared the space and see what happens16:16
KinnisonOh you cleared stuff?16:16
KinnisonI didn't ask you to clear anything16:17
* Kinnison is confused 16:17
pedroalvarezKinnison: everything is possible I guess, I have to take a look at it16:17
Kinnisonpedroalvarez: :-)16:17
* paulsher1ood has never seen a build fail on space - has seen builds *refuse to start* on space though16:18
Zara_Kinnison: sorry, I meant I cleared it according to the wiki pg I was referred to, sorry, for some reason I thought you'd linked me but it wasn't you16:18
Zara_I am very sleepy today :/16:18
KinnisonZara_: could you pastebin the output of morph --dump-config ?16:19
Zara_Kinnison: here:
KinnisonOkay, that does look sane16:20
Zara_could I cause something like this by putting the wrong upetrify-ref or ref in a stratum? because that's the last thing I changed16:22
Kinnisonseems unlikely16:22
KinnisonIs there anything clearly dodgy in the end of the dmesg ?16:22
Zara_I don't know enough about it to know what counts as 'dodgy'; the last line is: [13541.806536] kworker/u4:8 (5038) used greatest stack depth: 11016 bytes left16:23
KinnisonI'd be looking for anything suggesting the filesystems were bad16:24
SotKis there an easy way of generating the manifest files used by install-files?16:40
KinnisonI believe up until now, by-hand is what we have16:42
franredSotK, there are examples on g.b.o, or you are asking for an script?16:42
SotKI was hoping for a script, but thought it was by-hand16:43
franredSotK, I am doing it by hand for Openstack16:43
ssam2patches to improve install-files gratefully accepted!16:44
persiaIs there a common use case for install-files that we can work around in a different way?16:44
ssam2installing files in the system is a pretty common use case16:45
* persia interpreted install-files as a catch all when nothing else worked, but not intended for regular use for more than a couple files.16:45
* SotK vaguely remembers there being a proposal to use a yaml manifest file16:45
persiassam2: Yes, but installing *what class* of files?16:45
persiaFor example, we added something different for ssh keys, to avoid the messiness.16:45
ssam2persia: good question16:45
franredpersia, for example systemd units16:46
persiaIf these are support files for software, or common configuration, or something, I'm not sure that we can't make a better, more specific tool to handle it.16:46
ssam2configuration fluff is the main thing, I think16:46
* SotK doesn't remember if the ssh-key extension ever got merged16:46
franredconfiguration fluff16:46
persiaAnd if we have *enough* files that people are looking for a script to create an install-files manifest, I think we have such a use case.16:46
persiafranred: configuration for specific chunks?  Can that be delivered at system-integration-time, or does it require deploy-time decisions to have been made?16:47
persiaCan we do something where we pre-install templates with a config chunk, and have ansible parse the templates and add deployment specifics at first-boot?16:47
persiaShould we have a config-files write extension, so that chunks drop their configuration files in some location, and they get added at the appropriate time?16:48
franredpersia, I agree some of them will be re-written in ansible at some point, and maybe it is worth add some systemd units to the chunk morphology rather than having them on a configuration extension16:48
ssam2persia: installing config templates and Ansible scripts in a chunk is what we do for Trove systems currently16:48
ssam2and it works OK16:48
persiassam2: That is where I got the idea :)16:49
persiafranred: That would be my thought, yes.  Adding a bunch of random files with install-files seems heavy-handed.16:50
* SotK wonders how long its likely to take the lorry he merged to be run16:50
franredpersia, but you only need to deploy them and not build them16:50
persiaSotK: In my experience, 2-3 hours.  Don't bother waiting to submit something for review.  Clone a local copy if you want to test it.16:51
franredI mean, if you add the systemd units to the chuncks you need to build the chunck to have them in, when if you have them as files and add them via manifest you only need to deploy the system to add the new changes16:51
persiafranred: In that case, I'm even more certain they belong in the chunk directly.16:51
SotKbeing able to shove them in without rebuilding is useful for development16:52
persiaPersonally, I tend to edit-in-place on a test system, and then copy back to a repo when it is good :)16:53
franredpersia, how do you test services which configuring things on first boot?16:55
persiaI've never done that for systems that had deployment automation, so I generally loop-mounted and adjusted.16:56
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 250 seconds]16:56
persiaFor automated deployment, for first boot stuff, I'd probably try to do it in Ansible from the start, because I wouldn't want to troubleshoot twice, but that's a theoretical opinion16:57
ssam2anyone seen: 'ERROR: cannot create subvolume - Read-only file system' from `morph deploy` before ?17:03
ssam2I am the breaker of all things today, it seems17:03
ssam2maybe my DISK_SIZE is too small, I suppose17:05
rjekIf that's the case, the error is not very helpful.17:06
*** Krin [] has quit [Ping timeout: 244 seconds]17:15
ssam2seems to have got further this time, so I guess it was indeed DISK_SIZE17:15
ssam2another instance of filling up a btrfs disk causing confusing errors, I guess...17:16
*** tiagogomes [~tiagogome@] has joined #baserock17:20
*** Krin [] has joined #baserock17:20
radiofreemy favourite morph message is "deleting temporary directory: failed"17:22
persiaThis is my least favourity message.  We've talked about it several times as silly, because of the context change, but never figured out how to fix it sanely.17:24
Zara_I thought the use of 'favourity' was a bit uncharacteristic17:24
radiofreejust print the full path?17:25
radiofreedeleting temporary directory: /src/tmp/failed17:25
ssam2radiofree: I'd be happy with a patch that did that17:25
* persia also17:25
ssam2myself, Fran and Pedro want to configure our instances at DataCentred so that all 3 of us have access to all of them17:26
ssam2anyone have pointers on the best way to do this?17:26
ssam2OpenStack lets you automatically add 1 key to ~/.ssh/authorized_keys, but not 3 keys17:26
radiofreemanually add the other two?17:26
persiaEither add all three keys when creating an instance (would need more morph fanciness), or use a user script17:26
ssam2radiofree: I was hoping for a better way17:26
ssam2persia: most of these systems are not deployed with Morph at present17:27
pedroalvarezhm.. I think we can also add ssh keys in the cloud_config script17:27
ssam2it's tempting to just create a new SSH key which the 3 of us share17:27
persiaShared keys are bad17:27
ssam2hmm, cloud_config, that's a thought17:27
petefoth1SotK: thanks for the review of the documentation patches. There's one more still needing another +1 if you have time - I've resent it to the list17:28
persiaI've seen it done with cloud_config (what I called a "user script" in other contexts.17:29
pedroalvarezwrt - cloud config scripts: I found some info here
* ssam2 regrets building the Gerrit system locally instead of deploying it from a machine within the DataCentred cloud -- 20 minutes sat at 'Configuring OpenStack image...' and counting17:29
pedroalvarezseems easy to do, maybe we should check that it works in baserock17:29
ssam2so we could maintain a wiki page that listed a suitable cloud-config fragment that injected all 3 of our public keys into each instance17:30
ssam2that seems reasonable17:30
persiaI'd prefer that you kept that document in a git repo with some ACL, to make it harder for random folk to adjust it.17:31
ssam2good point17:31
pedroalvarezand a really good one :)17:32
persiaPlus, it means folk not in the operations team can submit patches for review sanely.17:32
Zara_I now have lots of notes for the import-tool tutorial (up to the 'fixing builder' section, where everything went wrong ;_;); shall I just add them straight to the wiki? The page says to report them to the mailing list but that'll take longer all ways round (and it *is* a wiki page!).17:33
*** Krin [] has quit [Ping timeout: 260 seconds]17:34
persiaZara_: If you have sensible edits, just do them.  Note that the wiki is a git repo, so you can clone it and use your favorite editor if you like (which also means your credit is easier for others to understand).17:34
ssam2Zara_: simple fixes, feel free to do them17:34
persiaIf you're unsure about something, if it is small, just paste a change here for a quick IRC review.17:35
ssam2if it's more in-depth review comments, please send them to the mailing list so we can discuss them17:35
persiaIf you are changing something really big, or really want review, or are adjusting policy, post the patchset to the mailing list.17:35
Zara_ok, great, thanks :) I don't think there's anything controversial so I'll just add them.17:35
persiaExcellent.  Extra points for doing it with git, rather than the edit-in-place messiness.17:36
*** tiagogomes [~tiagogome@] has quit [Ping timeout: 250 seconds]17:37
pedroalvarezssam2: I confirm that adding the ssh-keys using the cloud-config works17:39
ssam2during initial deployment?17:39
ssam2so we need to fix the existing VMs, but for new ones it'll be OK17:39
ssam2if you and franred PM me your public keys, I'll add them to a file in
ssam2even better if you can give me a working cloud-config script to adapt :)17:40
pedroalvarezthis is what I tested:
* persia is amused to see smoser's key used in this way17:46
ssam2bah, this documentation merge has proved really annoying17:51
ssam2luckily I'm still waiting for my image to upload to OpenStack, 40 minutes after starting it17:52
persiaIs this an issue with glance, or the network speed?17:53
ssam2I believe it's network speed17:53
DavePagessam2: Which OpenStack?17:56
*** mariaderidder [] has quit [Quit: Ex-Chat]17:56
*** Guest44939 [] has quit [Quit: Leaving]17:57
pedroalvarezthe one that we have in Datacentred 17:57
DavePageAh, OK, not ct-stack-217:58
ssam2DavePage: yes, it's external to the office17:59
ssam2still, I don't think it's an uncommon case to be deploying images to a cloud over the internet, and right now Morph is a horrid way to do that18:00
*** Krin [] has joined #baserock18:00
ssam2by comparison, Packer takes on the order 5 minutes to deploy an image to the same cloud18:00
ssam2but it works by booting an existing base image, then running commands inside it18:01
*** bashrc [] has quit [Quit: Lost terminal]18:02
ssam2actually, I'm being disingenous here. I found Packer fast at one point, but now the 'flavors' available in the cloud have changed such that 40GB is the minimum disk size I can give an instance18:03
ssam2and this causes Packer deployments to take ~20 mins, while it takes a snapshot of a 40GB instance18:04
ssam2and then another ~20 mins to boot it18:04
ssam2in conclusion, everything sucks.18:04
persiaThe fastest way is probaby to have something like Ansible or salt pull definitions master, and build/deploy a baserock image from inside the cloud.18:05
persiaThen you just have to push the instructions, and everything happens quickly.18:05
ssam2although you have to take the cost of CPU time inside the cloud into consideration18:06
persiaShouldn't be too much to build&deploy something from cache.18:07
persiaCertainly comparable to the CPU cost building anywhere else.18:07
ssam2CPU time on my laptop is free :)18:09
ssam2in our case, we run a Mason in the same cloud anyway, but I don't know if that'd work for every possible Baserock user18:10
persiaI'm just thinking about your case.  Different users have different situations.18:10
ssam2fair enough18:10
persiaBut CPU time on your laptop *isn't* free.  Someone pays for the power you are using (you may be getting it as a side benefit from having recently had your laptop in an airport lounge, for example).  Someone paid for the laptop, which is experiencing wear and tear, and so depreciating in value.18:11
persiaAt least for me, laptop time costs something on the order of 50 yen an hour (given a whole host of assumptions).18:12
persiaProbably lower than cloud fees, but still.18:12
ssam2thankfully, the days of having to feed 50p coins into the Codethink electricity meter are far behind us18:13
ssam2this >1 hour deployment has ended in '500 Internal Server Error'18:31
ssam2i'm so happy18:31
* Zara_ realises why there are multiple packs of tissues on the 302 table18:35
* petefoth1 is amused that persia sees the edit-in-place wiki functioanlity as 'messiness'. For petefoth it is a more user friendly and less messy user experience :)18:37
persiaI don't like the accredation associated with them18:38
petefoth1me looks up 'accredation'18:39
Zara_I prefer using the edit-in-place functionality, mainly due to the preview feature (I write long edits in an editor, then paste), so unfortunately I won't get those extra points18:40
* persia can't spell: accreditation18:40
persiaZara_: Makes sense.  I used to write long edits in browsers and got sick of the unreliability of browsers, and began to prefer editors, but I agree that local preview is annoying.18:41
petefoth1persia: I think that's a nug with ikiwiki - I sign in with an ID which identifies me clearly (my Codethink Google Docs ID) . Sadly ikiwiki is unable to pull out meaningful / useful information abotu who I actually am. 18:44
* petefoth1 can't spell bug18:44
petefoth1among other words :)18:45
persiaYou clearly win the "it's getting late" game :)18:45
petefoth1Do I et some xtra points? :)18:45
persiaBut yeah, there's two bugs: firstly that local preview is annoying, and second that not enough information is collected from the identity provider to populate the Author: field18:45
*** ssam2 [] has quit [Quit: Leaving]18:47
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]19:33
*** genii [~quassel@ubuntu/member/genii] has joined #baserock19:46
paulsher1oodpersia: ^^20:05
persiaExcellent.  More players in a post-package world!20:05
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection]23:35

Generated by 2.15.3 by Marius Gedminas - find it at!