| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 00:35 | |
| *** rdale_ [~quassel@68.Red-83-55-115.dynamicIP.rima-tde.net] has joined #baserock | 03:31 | |
| *** rdale [~quassel@169.Red-88-8-223.dynamicIP.rima-tde.net] 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 #baserock | 07:54 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:27 | |
| paulsher1ood | jjardon: i hope he means that we'll be starting to address some of wiki.baserock.org/wishlist | 08:29 |
|---|---|---|
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:51 | |
| mike is now known as Guest44939 | 08:52 | |
| * paulsher1ood has a baserock system with systemd, apparently configured network, which can't see the outside world... | 08:55 | |
| paulsher1ood | s/systemd/systemd217/ | 08:55 |
| paulsher1ood | any ideas how to debug this? | 08:55 |
| persia | I'd start with the output of `ifconfig -a` and `netstat -rn` | 08:58 |
| persia | The 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 [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| persia | I suspect that the dhcp client hasn't triggered for your interface | 09:00 |
| paulsher1ood | http://paste.baserock.org/oharijohin.sm | 09:05 |
| persia | Interesting. You seem to have two different network interfaces, only one of which is routing. | 09:07 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| persia | Do you know if 10.24.1.1 is in your gateway path to the internet? | 09:08 |
| persia | If so, it looks like it *should* work. | 09:09 |
| persia | Try a ping of 10.24.1.1 to verify. | 09:09 |
| persia | If that works, try traceroute to some known external source. | 09:09 |
| paulsher1ood | PING 10.24.1.1 (10.24.1.1): 56 data bytes | 09:10 |
| paulsher1ood | 64 bytes from 10.24.1.1: seq=0 ttl=64 time=83.075 ms | 09:10 |
| paulsher1ood | traceroute/ping for external hangs | 09:10 |
| persia | For external, did you use a name, or an IP? | 09:11 |
| paulsher1ood | name | 09:11 |
| persia | Try IP. | 09:12 |
| persia | e.g. 8.8.8.8 | 09:12 |
| persia | It may be that your name service is broken, rather than your network. | 09:12 |
| persia | If 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 |
| paulsher1ood | ping 8.8.8.8 works. traceroute 74.125.230.102 hangs | 09:13 |
| paulsher1ood | should /etc/resolv.conf get populated with something by default? | 09:14 |
| persia | That would be a name issue. `traceroute -n 74.125.230.102` should work. | 09:14 |
| persia | Your DHCP server should provide some nameservers | 09:15 |
| persia | If it isn't, or your DHCP client is broken, you can fix it by adding one manually | 09:15 |
| paulsher1ood | it is, but the names are down (i expect i originally created this vm somewhere else) | 09:16 |
| persia | e.g. `echo nameserver 8.8.8.8 > /etc/resolv.conf`, if you don't mind telling Google when you do lookups. | 09:16 |
| paulsher1ood | yay. | 09:16 |
| paulsher1ood | i tell google everything anyway :) | 09:16 |
| persia | Heh | 09:16 |
| * paulsher1ood had 192.168.4.100 and 192.168.8.100 in /etc/resolv.conf .. can't remember adding them | 09:18 | |
| persia | Might 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 baserock | 09:19 | |
| * SotK misses morph petrify | 09:20 | |
| persia | SotK: Why? | 09:20 |
| SotK | I'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 result | 09:21 |
| paulsher1ood | has morph petrify actually been removed? | 09:22 |
| persia | Ah, 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 |
| SotK | paulsher1ood: yep | 09:23 |
| persia | paulsher1ood: d63f41dadf5aa96a8d9254d31e92711ee160245e removed it in August | 09:23 |
| SotK | persia: indeed, I don't care for unpetrify, I just don't like finding SHAs and think a computer should do it for me | 09:24 |
| persia | Agreed. 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@213.15.255.100] has joined #baserock | 09:27 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:35 | |
| *** locallycompact [~lc@91.125.108.8] has joined #baserock | 09:56 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 09:59 | |
| *** sam__ [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 09:59 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:06 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:21 | |
| Mode #baserock +v ssam2 by ChanServ | 10:21 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:29 | |
| Krin | does 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 symlink | 10:39 |
| ssam2 | so you can create the symlink manually | 10:39 |
| ssam2 | if you run a 'systemctl enable' command I think it tells you what link it created, so just try it and go from there | 10:39 |
| ssam2 | there's no magic at work in the 'enable' command | 10:40 |
| Krin | thanks ssam2 :) | 10:40 |
| petefoth | How long will pastes posted to http://paste.baserock.org/ be kept? | 10:43 |
| pedroalvarez | petefoth: I think you have to assume that they can dissapear | 10:43 |
| pedroalvarez | or disappear | 10:44 |
| petefoth | pedroalvarez: Or both :) Thanks | 10:44 |
| pedroalvarez | petefoth: here there is some info: http://paste.baserock.org/about.md | 10:44 |
| ssam2 | the Gerrit system we have in master doesn't build, because it tries to write to /home at system-integration time and fails | 10:45 |
| ssam2 | did we deliberately prevent system-integration commands from writing to /home ? | 10:45 |
| * ssam2 wishes for Richard Maw | 10:46 | |
| petefoth | ...which says 'Pastes will stay for 30 days from their last view. They may be removed earlier | 10:46 |
| petefoth | and without notice.' Just what I needed to know :) | 10:46 |
| SotK | Can I get a quick review on http://paste.baserock.org/yisovolaqi.diff please? | 11:29 |
| SotK | Its a dependency for turbo-hipster, and it doesn't seem worth sending to the list for one lorry | 11:30 |
| pedroalvarez | SotK: +1 | 11:30 |
| franred | SotK, +1 | 11:31 |
| SotK | thanks :) | 11:31 |
| SotK | merged | 11:32 |
| *** locallycompact [~lc@91.125.108.8] has quit [Ping timeout: 272 seconds] | 11:33 | |
| ssam2 | seems that my problem with Gerrit is not copying the file, but changing the permissions after it has been copied ... | 11:33 |
| paulsher1ood | is it fixable? | 11:36 |
| persia | Can the permissions be set by using install, rather than cp? | 11:38 |
| ssam2 | the permissions are being set using 'install' | 11:39 |
| ssam2 | well, attempting to be set | 11:39 |
| ssam2 | paulsher1ood: it can certainly be worked around, but it's not clear to me what the best/quickest option will be yet | 11:39 |
| ssam2 | install returns: install: can't change ownership of /home/gerrit2/gerrit/gerrit-2.9.war: Operation not permitted | 11:40 |
| persia | Hrm. Annoying. | 11:44 |
| franred | ssam2, 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 |
| franred | s/folder/directory/ | 11:45 |
| ssam2 | I will try that | 11:45 |
| ssam2 | I'm currently trying to reproduce the problem outside Morph, but there is a lot of shell wizardly to disentangle | 11:45 |
| ssam2 | *wizardry | 11:45 |
| franred | Im 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 |
| ssam2 | I feel it'd be better if you create a separate one for now | 11:49 |
| ssam2 | it'd be easier to combine two kernel configs later on, than to separate one massive kernel config | 11:49 |
| persia | Also, it means that a lot of the non-virtual stuff can be dropped from the virtualisation kernel. | 11:49 |
| persia | That said, I've seen teams with separate configs recombine them because it can be annoying ensure the common configuration choices are consistent. | 11:50 |
| ssam2 | I 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 config | 11:50 |
| paulsher1ood | +1 for a separate virtualization kernel, especially if it can include the stuffs for docker | 11:50 |
| ssam2 | although as long as changes to the configs have good commit messages, it's not a critical problem | 11:51 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:55 | |
| paulsher1ood | if 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 |
| Kinnison | paulsher1ood: 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 else | 11:58 |
| Zara_ | or something else entirely? :) | 11:58 |
| ssam2 | Zara_: replace /usr/bin/baserock-import with a shell script that runs the tool from /src/import | 11:59 |
| paulsher1ood | Kinnison: which tools? it seems morph petrify is deprecated? | 11:59 |
| Zara_ | ssam2: Ah, ok, thanks :) | 12:00 |
| Kinnison | paulsher1ood: Well persia wanted a tool | 12:00 |
| Kinnison | paulsher1ood: people seem to want to be able to have names *or* shas, particularly when developing something | 12:00 |
| Kinnison | paulsher1ood: which implies wanting help to lock it down when they're done with development | 12:00 |
| persia | But I don't want SHAs in the structure YAML anyway :) | 12:00 |
| ssam2 | I think taking refs out of definitions is a pretty good idea, having had a while to consider it | 12:00 |
| persia | I want refs in definitions, but in a different file. | 12:00 |
| ssam2 | that's what I meant :) | 12:01 |
| persia | Just a simple mapping of chunk names to refs. | 12:01 |
| SotK | +1 | 12:01 |
| ssam2 | in fact, I was going to mention this in my reply to the 'feature wishlist', but I've not had time to finish it off yet | 12:01 |
| paulsher1ood | ok provided chunk names are unique | 12:01 |
| persia | Note that I want *repos* in the chunk names. | 12:01 |
| persia | paulsher1ood: Your @ patch allows this. | 12:01 |
| persia | Err, repos in the definitions YAML | 12:02 |
| ssam2 | persia: phew | 12:02 |
| paulsher1ood | persia: agreed, but there's more non-uniques to cleanup | 12:02 |
| persia | Apologies for the confusion : | 12:02 |
| persia | paulsher1ood: True, but not many, and I think we have consensus that we all want unique. | 12:02 |
| persia | If 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 fails | 12:03 | |
| bashrc | I thought repos were defined in morph files already | 12:04 |
| persia | bashrc: 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 |
| persia | The idea being that they fork something ,and then want to track refs in the fork, and only do it in one place. | 12:05 |
| bashrc | persia: doesn't that just create unnecessary work? | 12:05 |
| persia | My 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 |
| paulsher1ood | persia: quite a few... http://paste.baserock.org/ociwefecum.vhdl | 12:06 |
| persia | I 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 | |
| persia | paulsher1ood: 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 created | 12:07 | |
| paulsher1ood | it's ybd | 12:08 |
| paulsher1ood | so just a few python scripts, no dependencies | 12:08 |
| persia | Heh. But ybd does so much more, making it perhaps overkill for just this. Still, worth considering. | 12:09 |
| paulsher1ood | i reckon the part that does this output is ~100 lines in total | 12:13 |
| persia | I 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 use | 12:19 |
| * persia would prefer to skip the human involvement most of the time | 12:24 | |
| rdale_ | yes, but it's like giving some a database schema, and saying 'here's psql, get on with it' | 12:25 |
| bashrc | optimising for readability is better than optimising for efficiency if humans are expected to be doing the maintenance/development | 12:26 |
| rdale_ | we shouldn't be working a such a low level, that exactly where the name of a repo is stored actually matters | 12:27 |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 12:28 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 12:28 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 12:28 | |
| persia | For 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 yaml | 12:33 |
| persia | No, 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 |
| persia | I 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 |
| persia | So, 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 |
| pedroalvarez | I'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 |
| paulsher1ood | just go ahead, assuming it's a baserock project - you have the powers | 12:39 |
| paulsher1ood | (ie asssuming it's a baserock:baserock/foo or similar) | 12:40 |
| pedroalvarez | yes, a baserock:baserock/foo repo. I don't have the powers actually. | 12:41 |
| paulsher1ood | really? | 12:41 |
| pedroalvarez | :) | 12:41 |
| paulsher1ood | what would you like it to be called? | 12:41 |
| * paulsher1ood has/had the powers | 12:42 | |
| pedroalvarez | baserock:baserock/installer-scripts | 12:42 |
| paulsher1ood | pedroalvarez: shoudl be there now | 12:44 |
| paulsher1ood | are you sure you don't have the powers? | 12:44 |
| paulsher1ood | (the command was morph trovectl create baserock/baserock/installer-scripts) | 12:45 |
| pedroalvarez | paulsher1ood: well, I haven't tried, but I think I have to be in one of the gitano groups to be able to create repos | 12:46 |
| paulsher1ood | i assume you're in baserock-writers | 12:46 |
| pedroalvarez | yes | 12:46 |
| paulsher1ood | i think that's all you need (maybe baserock-admins) | 12:47 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 12:47 | |
| paulsher1ood | anyways, it's done :) | 12:48 |
| franred | ssam2, building gerrit in a VM fails in the same way | 12:49 |
| pedroalvarez | paulsher1ood: tvm :) | 12:50 |
| ssam2 | seems that running system-integration commands inside linux-user-chroot causes 'chown' to no longer work | 12:52 |
| ssam2 | I have no idea the best thing to do about this so I'll send a mail to the list and work around the problem | 12:52 |
| paulsher1ood | persia: http://paste.baserock.org/anoxenavex.py (103 lines, excluding header... works on .morph files) | 13:02 |
| persia | paulsher1ood: heh. That is indeed small enough to be a useful part of acceptance testing for definitions. Please consider submitting it to scripts/ :) | 13:03 |
| paulsher1ood | i would prefer if morph could use this logic directly, and output the warnings itself :) | 13:05 |
| persia | Having that class of logic in the default build tool would indeed be preferable. | 13:07 |
| Krin | could 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 |
| pedroalvarez | Krin: it's normal git :) | 13:09 |
| Kinnison | For stratum changes, it's normal git | 13:09 |
| Krin | woo! *goes to cause chaos fire and confusion... and hopefully pushes* | 13:10 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 13:31 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:40 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:51 | |
| pedroalvarez | meh, I misunderstood one of Richard Maw's emails and I did the wrong thing. He wanted me to put the installer.py script in /usr/lib/baserock-installer/installer.py, 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: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/installer-scripts.git/tree/ | 14:02 |
| paulsher1ood | radiofree: can we use mainline v3.18 kernel for jetson systems by default now? | 14:27 |
| radiofree | nope | 14:29 |
| radiofree | or maybe... | 14:30 |
| radiofree | cyndis: has the cpufreq stuff made it into 3.18? | 14:30 |
| cyndis | no | 14:30 |
| cyndis | won't be in 3.19 either | 14:31 |
| cyndis | seems like the tegra clock maintainer has been busy | 14:31 |
| radiofree | is there anyway of achieve "performance" mode without it? | 14:31 |
| cyndis | nope | 14:32 |
| cyndis | i talked with him about it perhaps a week back | 14:32 |
| cyndis | (p2-mate) | 14:33 |
| radiofree | cyndis: ok, thanks for the info :) | 14:33 |
| cyndis | hopefully we can get it into 3.20.. :) | 14:33 |
| radiofree | i look forward to it :D | 14:35 |
| radiofree | paulsher1ood: so no, but we can use 3.18+cpufreq patches on top | 14:35 |
| paulsher1ood | is there a branch on gbo containing (just) the cpufreq | 14:38 |
| paulsher1ood | so would that just be a matter of 'git merge baserock/james/jetson-3.17-rc5-cpufreq' on 3.18? | 14:39 |
| radiofree | we're not using that 3.17 branch | 14:39 |
| paulsher1ood | i know, i'm just looking for shortest way to get to a tidy solution :) | 14:40 |
| radiofree | git cherry-pick 548897e193584ebcfb156abb740217f5e4f4ca3^..91d36393893d4dfc83894bff421a81210031aeff | 14:41 |
| radiofree | should do it | 14:41 |
| franred | probably, 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 |
| paulsher1ood | yup | 14:41 |
| paulsher1ood | radiofree: fatal - bad revision | 14:44 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 14:44 | |
| radiofree | paulsher1ood: oh dear, i'll take a quick look | 14:44 |
| radiofree | paulsher1ood: sorry, i buggered up | 14:48 |
| radiofree | git cherry-pick 7548897e193584ebcfb156abb740217f5e4f4ca3^..91d36393893d4dfc83894bff421a81210031aeff | 14:48 |
| radiofree | applies cleanly | 14:48 |
| * paulsher1ood does that, and submits a patch | 14:58 | |
| paulsher1ood | (for v3.18) | 14:58 |
| radiofree | ok i'll test it now before i head off | 15:00 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:14 | |
| * SotK moans about projects with tagged releases which don't work | 15:17 | |
| * persia continues to disbelieve expecting upstream to provide useful tags is a worthwhile way to spend time | 15:24 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Read error: Connection reset by peer] | 15:28 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 15:28 | |
| cyndis | the 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 | |
| radiofree | paulsher1ood: works, +1 | 15:30 |
| radiofree | good to have a single kernel for all systems as well | 15:30 |
| radiofree | 0- | 15:31 |
| cyndis | yep. without the upstream project who knows where we'd be :) | 15:31 |
| persia | cyndis: 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 |
| persia | Mind you, not having the patch submitted upstream is unacceptable behaviour, as is ignoring it if it needs rework. | 15:33 |
| cyndis | yeah, i'm not saying that being fully upstream is a sensible solution, far from it | 15:33 |
| cyndis | there is clearly a need for both. it's just that they shouldn't be so diverged :) | 15:34 |
| cyndis | but of course it is a very difficult problem. | 15:35 |
| persia | Oh 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 |
| persia | Well, 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 |
| cyndis | yeah, i don't like linux's mailing list patch process at all | 15:36 |
| persia | I 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 |
| persia | git-am is also helpful (unsurprisingly, as it was written for this purpose) | 15:38 |
| cyndis | yeah, but then sometimes they don't, and.. | 15:38 |
| cyndis | git am is sometimes helpful but sometimes not, since you don't know the commit the series was built on | 15:38 |
| persia | But 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 |
| persia | True on both points :) | 15:39 |
| cyndis | i'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 |
| persia | There's been a few attempts to write patch trackers that process mailing lists, but most of them seem to wither over time. | 15:42 |
| persia | Either 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 |
| cyndis | yep. 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 :p | 15:46 |
| persia | I don't think anything else can work for linux. There is no meaningful trunk. | 15:47 |
| persia | Well there's Linus' tree, but that isn't necessarily the right basis or target for anything directly. | 15:47 |
| persia | Most projects have a canonical repository, which makes them more amenable to patch trackers against that repository. | 15:48 |
| perryl | how 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 question | 15:52 |
| perryl | s/five/six | 15:53 |
| persia | If you have a system with cron installed, I'd suggest adding something to /etc/crontab. | 15:54 |
| persia | If you can run as a non-root user, consider using that user's crontab. | 15:54 |
| pedroalvarez | I think that the right way to do this is using a systemd.timer | 15:54 |
| * persia suspects that to be a cleaner solution, with less extra components | 15:55 | |
| persia | s/less/fewer/ | 15:55 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:55 | |
| perryl | entirely possible; from the looks of it cron is good for a user-specific case, i will look into systemd.timer | 15:55 |
| pedroalvarez | perryl: it's pretty easy. Here there are some examples: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry-controller.git/tree/units | 15:56 |
| * SotK wonders what the procedure is for updating a tarball lorry? | 15:58 | |
| Kinnison | Change the URL | 15:59 |
| Kinnison | that should just about be it | 15:59 |
| persia | Doesn't changing the URL cause the generated repo to gain a commit? | 15:59 |
| Kinnison | Yes | 15:59 |
| perryl | pedroalvarez: 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.build | 16: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.build | 16:00 |
| franred | I though the new generated repo gain a branch | 16:01 |
| franred | Kinnison, persia ^^ ? | 16:01 |
| Zara_ | (tried searching the wiki for 'failed to copy file' but no luck) | 16:01 |
| pedroalvarez | perryl: it doesn't have to. | 16:01 |
| Kinnison | franred: it gains a tag and a new commit on master | 16:01 |
| franred | oh, ok | 16:02 |
| SotK | can I get a quick review on http://paste.baserock.org/fequmogebe.diff please, it seems the version I found on pypi first time didn't work | 16:02 |
| ssam2 | SotK: seems fine, +1 | 16:06 |
| pedroalvarez | SotK: also to me | 16:06 |
| * paulsher1ood wonders if anyone else would be interested in +1 and merging the 3.18 patch | 16:06 | |
| SotK | thanks | 16:06 |
| pedroalvarez | I wonder if any particular test should be done, although I've seen a lot of kernel upgrades in baserock that just work | 16:07 |
| ssam2 | paulsherwood: I'm in the process of testing it | 16: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 graphics | 16:08 | |
| paulsher1ood | ooh, cool. did you fix the gerrit issue, ssam2 ? | 16:08 |
| Zara_ | can anyone help me with the error I mentioned above? | 16:09 |
| ssam2 | paulsher1ood: I will work around the issue that I was discussing here earlier | 16:10 |
| rjek | Zara_: How much disc space is there in /src free? | 16:10 |
| mwilliams_ct | Zara_: http://wiki.baserock.org/guides/build-failures/ any use? Might be out of disk space | 16:10 |
| rjek | snappish | 16:10 |
| Zara_ | it's a different error, though that might just mean the message has changed | 16:10 |
| Kinnison | I'd check free space | 16:10 |
| Kinnison | esp. in your tempdir and cachedir | 16:11 |
| Zara_ | Ok, I'll try it out now :) If it works, I'll add that error message to the wiki so it's searchable | 16:11 |
| paulsher1ood | Zara_: please paste the result of df somewhere? | 16:11 |
| persia | franred: 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 |
| paulsher1ood | Zara_: (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: http://paste.baserock.org/ubihohagiv.erlang_repl | 16:14 |
| franred | persia, 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 history | 16:14 |
| Zara_ | the command is useful for me to know in the future, though, thanks :) | 16:14 |
| Kinnison | Zara_: and your morph.conf has tempdir and cachedir set inside /src ? | 16:14 |
| Zara_ | I think so; I configured it according to the wiki instructions | 16:15 |
| persia | franred: That is my understanding, yes. | 16:15 |
| Kinnison | Zara_: 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 |
| Kinnison | pedroalvarez: 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 src | 16:16 |
| Kinnison | Zara_: most oddness | 16:16 |
| Zara_ | I'll try the command now I've cleared the space and see what happens | 16:16 |
| Kinnison | Oh you cleared stuff? | 16:16 |
| Kinnison | I didn't ask you to clear anything | 16:17 |
| * Kinnison is confused | 16:17 | |
| pedroalvarez | Kinnison: everything is possible I guess, I have to take a look at it | 16:17 |
| Kinnison | pedroalvarez: :-) | 16:17 |
| * paulsher1ood has never seen a build fail on space - has seen builds *refuse to start* on space though | 16: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 you | 16:18 |
| Zara_ | I am very sleepy today :/ | 16:18 |
| Kinnison | :-) | 16:18 |
| Kinnison | Zara_: could you pastebin the output of morph --dump-config ? | 16:19 |
| Zara_ | Kinnison: here: http://paste.baserock.org/izaviyuwom.hs | 16:20 |
| Kinnison | Okay, that does look sane | 16: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 changed | 16:22 |
| Kinnison | seems unlikely | 16:22 |
| Kinnison | Is 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 left | 16:23 |
| Kinnison | I'd be looking for anything suggesting the filesystems were bad | 16:24 |
| SotK | is there an easy way of generating the manifest files used by install-files? | 16:40 |
| Kinnison | I believe up until now, by-hand is what we have | 16:42 |
| franred | SotK, there are examples on g.b.o, or you are asking for an script? | 16:42 |
| SotK | I was hoping for a script, but thought it was by-hand | 16:43 |
| franred | SotK, I am doing it by hand for Openstack | 16:43 |
| ssam2 | patches to improve install-files gratefully accepted! | 16:44 |
| persia | Is there a common use case for install-files that we can work around in a different way? | 16:44 |
| ssam2 | installing files in the system is a pretty common use case | 16: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 file | 16:45 | |
| persia | ssam2: Yes, but installing *what class* of files? | 16:45 |
| persia | For example, we added something different for ssh keys, to avoid the messiness. | 16:45 |
| ssam2 | persia: good question | 16:45 |
| franred | persia, for example systemd units | 16:46 |
| persia | If 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 |
| ssam2 | configuration fluff is the main thing, I think | 16:46 |
| * SotK doesn't remember if the ssh-key extension ever got merged | 16:46 | |
| franred | configuration fluff | 16:46 |
| persia | And 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 |
| persia | franred: 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 |
| persia | Can 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 |
| persia | Should 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 |
| franred | persia, 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 extension | 16:48 |
| ssam2 | persia: installing config templates and Ansible scripts in a chunk is what we do for Trove systems currently | 16:48 |
| ssam2 | and it works OK | 16:48 |
| persia | ssam2: That is where I got the idea :) | 16:49 |
| persia | franred: 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 run | 16:50 | |
| franred | persia, but you only need to deploy them and not build them | 16:50 |
| persia | SotK: 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 |
| franred | I 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 changes | 16:51 |
| persia | franred: In that case, I'm even more certain they belong in the chunk directly. | 16:51 |
| SotK | being able to shove them in without rebuilding is useful for development | 16:52 |
| persia | Personally, I tend to edit-in-place on a test system, and then copy back to a repo when it is good :) | 16:53 |
| franred | persia, how do you test services which configuring things on first boot? | 16:55 |
| persia | I've never done that for systems that had deployment automation, so I generally loop-mounted and adjusted. | 16:56 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 250 seconds] | 16:56 | |
| persia | For 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 opinion | 16:57 |
| ssam2 | anyone seen: 'ERROR: cannot create subvolume - Read-only file system' from `morph deploy` before ? | 17:03 |
| ssam2 | I am the breaker of all things today, it seems | 17:03 |
| ssam2 | maybe my DISK_SIZE is too small, I suppose | 17:05 |
| rjek | If that's the case, the error is not very helpful. | 17:06 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 17:15 | |
| ssam2 | seems to have got further this time, so I guess it was indeed DISK_SIZE | 17:15 |
| ssam2 | another instance of filling up a btrfs disk causing confusing errors, I guess... | 17:16 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 17:20 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:20 | |
| radiofree | my favourite morph message is "deleting temporary directory: failed" | 17:22 |
| persia | This 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 |
| persia | s/ty/te/ | 17:24 |
| Zara_ | I thought the use of 'favourity' was a bit uncharacteristic | 17:24 |
| radiofree | just print the full path? | 17:25 |
| radiofree | deleting temporary directory: /src/tmp/failed | 17:25 |
| ssam2 | radiofree: I'd be happy with a patch that did that | 17:25 |
| * persia also | 17:25 | |
| ssam2 | myself, Fran and Pedro want to configure our instances at DataCentred so that all 3 of us have access to all of them | 17:26 |
| ssam2 | anyone have pointers on the best way to do this? | 17:26 |
| ssam2 | OpenStack lets you automatically add 1 key to ~/.ssh/authorized_keys, but not 3 keys | 17:26 |
| radiofree | .authorized_keys? | 17:26 |
| radiofree | oh | 17:26 |
| radiofree | manually add the other two? | 17:26 |
| persia | Either add all three keys when creating an instance (would need more morph fanciness), or use a user script | 17:26 |
| ssam2 | radiofree: I was hoping for a better way | 17:26 |
| ssam2 | persia: most of these systems are not deployed with Morph at present | 17:27 |
| pedroalvarez | hm.. I think we can also add ssh keys in the cloud_config script | 17:27 |
| ssam2 | it's tempting to just create a new SSH key which the 3 of us share | 17:27 |
| persia | Shared keys are bad | 17:27 |
| ssam2 | hmm, cloud_config, that's a thought | 17:27 |
| petefoth1 | SotK: 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 list | 17:28 |
| persia | I've seen it done with cloud_config (what I called a "user script" in other contexts. | 17:29 |
| pedroalvarez | wrt - cloud config scripts: I found some info here http://cloudinit.readthedocs.org/en/latest/topics/examples.html | 17:29 |
| persia | s/t"/t")/ | 17:29 |
| * 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 counting | 17:29 | |
| pedroalvarez | seems easy to do, maybe we should check that it works in baserock | 17:29 |
| ssam2 | so we could maintain a wiki page that listed a suitable cloud-config fragment that injected all 3 of our public keys into each instance | 17:30 |
| ssam2 | that seems reasonable | 17:30 |
| persia | I'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 |
| ssam2 | good point | 17:31 |
| pedroalvarez | and a really good one :) | 17:32 |
| persia | Plus, 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 [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 17:34 | |
| persia | Zara_: 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 |
| ssam2 | Zara_: simple fixes, feel free to do them | 17:34 |
| persia | If you're unsure about something, if it is small, just paste a change here for a quick IRC review. | 17:35 |
| ssam2 | if it's more in-depth review comments, please send them to the mailing list so we can discuss them | 17:35 |
| persia | If 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 |
| persia | Excellent. Extra points for doing it with git, rather than the edit-in-place messiness. | 17:36 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 250 seconds] | 17:37 | |
| pedroalvarez | ssam2: I confirm that adding the ssh-keys using the cloud-config works | 17:39 |
| ssam2 | during initial deployment? | 17:39 |
| pedroalvarez | yup | 17:39 |
| ssam2 | so we need to fix the existing VMs, but for new ones it'll be OK | 17:39 |
| ssam2 | if you and franred PM me your public keys, I'll add them to a file in http://github.com/ssssam/test-baserock-infrastructure | 17:40 |
| ssam2 | even better if you can give me a working cloud-config script to adapt :) | 17:40 |
| pedroalvarez | this is what I tested: http://paste.baserock.org/esolefadiy | 17:40 |
| * persia is amused to see smoser's key used in this way | 17:46 | |
| ssam2 | bah, this documentation merge has proved really annoying | 17:51 |
| ssam2 | luckily I'm still waiting for my image to upload to OpenStack, 40 minutes after starting it | 17:52 |
| persia | Is this an issue with glance, or the network speed? | 17:53 |
| ssam2 | I believe it's network speed | 17:53 |
| DavePage | ssam2: Which OpenStack? | 17:56 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:56 | |
| *** Guest44939 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:57 | |
| pedroalvarez | the one that we have in Datacentred | 17:57 |
| DavePage | Ah, OK, not ct-stack-2 | 17:58 |
| ssam2 | DavePage: yes, it's external to the office | 17:59 |
| ssam2 | still, 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 that | 18:00 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:00 | |
| ssam2 | by comparison, Packer takes on the order 5 minutes to deploy an image to the same cloud | 18:00 |
| ssam2 | but it works by booting an existing base image, then running commands inside it | 18:01 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:02 | |
| ssam2 | actually, 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 instance | 18:03 |
| ssam2 | and this causes Packer deployments to take ~20 mins, while it takes a snapshot of a 40GB instance | 18:04 |
| ssam2 | and then another ~20 mins to boot it | 18:04 |
| ssam2 | in conclusion, everything sucks. | 18:04 |
| persia | The 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 |
| persia | Then you just have to push the instructions, and everything happens quickly. | 18:05 |
| ssam2 | indeed | 18:06 |
| ssam2 | although you have to take the cost of CPU time inside the cloud into consideration | 18:06 |
| persia | Shouldn't be too much to build&deploy something from cache. | 18:07 |
| persia | Certainly comparable to the CPU cost building anywhere else. | 18:07 |
| ssam2 | CPU time on my laptop is free :) | 18:09 |
| ssam2 | in our case, we run a Mason in the same cloud anyway, but I don't know if that'd work for every possible Baserock user | 18:10 |
| persia | I'm just thinking about your case. Different users have different situations. | 18:10 |
| ssam2 | fair enough | 18:10 |
| persia | But 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 |
| persia | At least for me, laptop time costs something on the order of 50 yen an hour (given a whole host of assumptions). | 18:12 |
| persia | Probably lower than cloud fees, but still. | 18:12 |
| ssam2 | thankfully, the days of having to feed 50p coins into the Codethink electricity meter are far behind us | 18:13 |
| persia | heh | 18:14 |
| ssam2 | this >1 hour deployment has ended in '500 Internal Server Error' | 18:31 |
| ssam2 | i'm so happy | 18:31 |
| * Zara_ realises why there are multiple packs of tissues on the 302 table | 18: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 | |
| persia | I don't like the accredation associated with them | 18:38 |
| petefoth1 | me 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 points | 18:40 |
| * persia can't spell: accreditation | 18:40 | |
| persia | Zara_: 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 |
| petefoth1 | persia: 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 bug | 18:44 | |
| petefoth1 | among other words :) | 18:45 |
| persia | You clearly win the "it's getting late" game :) | 18:45 |
| petefoth1 | Do I et some xtra points? :) | 18:45 |
| persia | But 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: field | 18:45 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] 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 #baserock | 19:46 | |
| paulsher1ood | http://www.markshuttleworth.com/archives/1434 | 20:02 |
| paulsher1ood | persia: ^^ | 20:05 |
| persia | Excellent. 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 irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!