| *** zoli__ has joined #baserock | 05:43 | |
| *** zoli__ has quit IRC | 06:02 | |
| *** zoli__ has joined #baserock | 06:13 | |
| *** zoli__ has quit IRC | 06:47 | |
| *** zoli__ has joined #baserock | 06:51 | |
| *** petefoth1ringham has joined #baserock | 07:29 | |
| *** zoli__ has quit IRC | 07:46 | |
| *** a1exhughe5 has joined #baserock | 07:58 | |
| *** gfinney has joined #baserock | 08:13 | |
| *** gfinney_ has joined #baserock | 08:13 | |
| *** gfinney has quit IRC | 08:13 | |
| *** gfinney_ has quit IRC | 08:13 | |
| *** gfinney has joined #baserock | 08:13 | |
| *** gfinney_ has joined #baserock | 08:14 | |
| gfinney_ | good morning bench | 08:14 |
|---|---|---|
| petefoth | gfinney_: close. 'bench' != 'baserock' ;) | 08:15 |
| gfinney_ | Ah. Sorry | 08:15 |
| gfinney_ | It's that thing in the morning where it does lots of catching up | 08:16 |
| *** gfinney has quit IRC | 08:16 | |
| *** gfinney_ has quit IRC | 08:17 | |
| *** gfinney has joined #baserock | 08:17 | |
| *** gfinney_ has joined #baserock | 08:17 | |
| *** gfinney has quit IRC | 08:17 | |
| *** jonathanmaw has joined #baserock | 08:25 | |
| SotK | http://mason-x86-64.baserock.org/ is red :( | 08:56 |
| *** petefotheringham has quit IRC | 08:57 | |
| *** petefoth1ringham has quit IRC | 08:57 | |
| SotK | python-prettytable is failing because it can't find setuptools | 08:57 |
| *** petefotheringham has joined #baserock | 08:57 | |
| SotK | I guess whichever stratum python-prettytable is in didn't get its build-depends updated when setuptools went in python-core | 08:58 |
| petefotheringham | :quit | 08:59 |
| radiofree | it needs to depend on python-core now | 08:59 |
| *** petefotheringham has quit IRC | 08:59 | |
| pedroalvarez | anybody patching it? | 09:00 |
| SotK | I can send one | 09:00 |
| *** petefotheringham has joined #baserock | 09:01 | |
| *** bashrc has joined #baserock | 09:02 | |
| pedroalvarez | oh, py prettytable duplicated | 09:04 |
| SotK | yep, want me to move it into python-core in this fix too? | 09:05 |
| pedroalvarez | hm.. no, I think these things should't go to python-core | 09:05 |
| pedroalvarez | I was going to de the same for some python dependencies from ansible, and people didn't like the idea | 09:06 |
| SotK | do we need a different stratum for things like this then? python-common or similar? | 09:06 |
| pedroalvarez | that is what I was thinking | 09:06 |
| pedroalvarez | python-utils maybe? | 09:07 |
| pedroalvarez | we can discuss it today | 09:07 |
| *** mwilliams_ct has joined #baserock | 09:27 | |
| *** benbrown_ has joined #baserock | 09:27 | |
| *** tiagogomes_ has joined #baserock | 09:29 | |
| *** CTtpollard has joined #baserock | 09:33 | |
| *** gary_perkins has joined #baserock | 09:52 | |
| *** franred has joined #baserock | 09:52 | |
| SotK | \o/ mason is green again | 09:52 |
| pedroalvarez | :) | 09:54 |
| *** Krin has joined #baserock | 10:06 | |
| *** pdar has joined #baserock | 10:09 | |
| *** ssam2 has joined #baserock | 10:10 | |
| *** ChanServ sets mode: +v ssam2 | 10:10 | |
| franred | hi, we have markupsafe duplicated in ansible.morph and openstack-common (in the openstack branch) could I move it to python-tools or do you think is better to move to python-core? The description of markupsafe is: "Implements a XML/HTML/XHTML Markup safe string for Python" | 10:25 |
| franred | what do the baserock folks think is better to move it? | 10:26 |
| pedroalvarez | I was looking at that last week | 10:26 |
| straycat | it's not really a tool, and it doesn't belong in core | 10:27 |
| straycat | *python-core | 10:27 |
| pedroalvarez | I agreed that python-core wasn't the place | 10:27 |
| straycat | so i'd make a new stratum for this sort of thing | 10:27 |
| pedroalvarez | python-utils? | 10:27 |
| pedroalvarez | markupsafe, paramiko, prettyyable... | 10:27 |
| SotK | +1 for python-utils | 10:27 |
| pedroalvarez | SotK also suggested python-common | 10:27 |
| straycat | i'm not sure about util, these are python libraries really aren't they | 10:29 |
| straycat | oh woohoo a bike shed | 10:30 |
| pedroalvarez | :D | 10:30 |
| pedroalvarez | hm.. python-libs? python-libraries? | 10:30 |
| ssam2 | i'm not sure why it doesn't belong in python-core, at least for now. | 10:31 |
| straycat | ssam2, the more stuff we lump in core the more unnecessary rebuilding | 10:32 |
| straycat | i really think we need to try have more separation | 10:32 |
| straycat | *and have | 10:32 |
| SotK | can anyone quickly explain to me how artifact fetching works using morph-cache-server? | 10:36 |
| franred | I agree with straycat, as soon as we create different strata to have more separation as soon as we don't have to suffer massive rebuilds | 10:36 |
| Kinnison | sotk: Do you mean morph fetching artifacts, or m-c-s fetching artifacts from a distbuild worker? | 10:36 |
| SotK | Kinnison: the latter :) | 10:37 |
| pedroalvarez | Well, we are now in a world that we don't care about rebuiilds.. because of Mason | 10:37 |
| Kinnison | the controller tells the trove's m-c-s the worker and the set of artifacts needed, the trove m-c-s then fetches all the files to a temporary location and once it has all of them, it atomically places them into the cache | 10:37 |
| pedroalvarez | buy I also agree | 10:37 |
| pedroalvarez | s/buy/but/ | 10:38 |
| Kinnison | then the controller m-c-s responds to the distbuild controller to say it is done | 10:38 |
| *** zarazaimeche has joined #baserock | 10:38 | |
| zarazaimeche | I've tried upgrading a to a devel system from the currently downloadable baserock build image, with no luck. I've also tried building franred's openstack-v3 branch, with no luck. The exact errors depend on the version of morph, but 'no module named setuptools' is a popular one. | 10:39 |
| *** zarazaimeche is now known as Zara | 10:39 | |
| radiofree | Zara: that has been fixed this morning | 10:40 |
| pedroalvarez | indeed, if that is the problem please, get the latest definitions | 10:40 |
| radiofree | Zara: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=a43cfbabc13dcee38827ccab55c8de7c5c6b1137 | 10:40 |
| straycat | python-common or python-libs both seem equally fine to me btw, i can't think of anything better at least | 10:41 |
| pedroalvarez | I'd avoid *-libs, just because of the suffixes of chunk splintting | 10:41 |
| radiofree | python-common fits the baserock nomenclature better | 10:42 |
| radiofree | at least, the one that's been established with the various *-common stratum | 10:42 |
| kejiahu | morning, I am trying to deploy a trove and a distbuild network to Moonshot M400 sleds, can I get some idea on what I need to do? | 10:42 |
| straycat | python-common sounds good then | 10:42 |
| radiofree | strata is the plural right? | 10:43 |
| * straycat nods | 10:43 | |
| pedroalvarez | python-common works also for me | 10:43 |
| Zara | great. :) Could we have some kind of warning on the channel when the definitions are known to be broken? I've wasted several days, updating definitions and/or morph frequently. If there's info somewhere else, where can I find it? | 10:43 |
| franred | ok, so python-common it is. | 10:43 |
| straycat | kejiahu, there are some trove guides on http://wiki.baserock.org/guides/ that may be of use | 10:43 |
| radiofree | Zara: http://mason-x86-64.baserock.org/ | 10:43 |
| * franred prepares the patch for it | 10:43 | |
| radiofree | Zara: if it's red, something's broken ;) | 10:43 |
| pedroalvarez | franred: what things do you plan to move? | 10:44 |
| * straycat wouldn't mind having mason notification in channel, but other people would probably find it annoying | 10:44 | |
| radiofree | although i don't think definitions has been broken for 'several days', perhaps you have some other issue? | 10:44 |
| franred | Zara, also openstack-v3 was patched this morning too, problem with ansible.morph which contains markupsafe and does not contain python-core | 10:44 |
| SotK | Kinnison: thanks | 10:44 |
| franred | pedroalvarez, I plan to move at first only markupsafe, which other want you me to move into python-common? | 10:45 |
| kejiahu | straycat, thanks, I have read the trove guides, it seems they are all for deployment to VMs. is there anything for bare metel? | 10:45 |
| radiofree | straycat: that would be good, as long as it was smart enough not to spam the channel every 3 minutes when a build continues to fail | 10:46 |
| pedroalvarez | let me move the ansible.morph chunks, I have a patch ready for that | 10:46 |
| franred | pedroalvarez, go for it | 10:46 |
| Kinnison | SotK: it was done that way to reduce the number of systems needing to be authorised to the write-interface of the cache server | 10:47 |
| pedroalvarez | there are others though | 10:47 |
| Kinnison | SotK: basically only the distbuild controller needs it in that model (though something for GCing it would need it too) | 10:47 |
| straycat | kejiahu, there's nothing specifically on deploying trove to bare metal there may be a more general guide for deploying baserock to bare metal though, richard_maw or pedroalvarez may know more about that | 10:47 |
| franred | pedroalvarez, yes, they will be, I think openstack-* has duplicity of some python packages present on other morphologies, if you can have a look at that would be good too | 10:47 |
| straycat | radiofree, yes :) | 10:47 |
| kejiahu | straycat, cheers | 10:47 |
| SotK | python-prettytable is one of them | 10:48 |
| * pedroalvarez will take a look at them | 10:48 | |
| Zara | can confrim that python-prettytable was one that was failing for me before. | 10:49 |
| richard_maw | kejiahu: mostly just that you probably want to have an initramfs, and unless you can easily take the disk out and put it in a dock to image it, you'll also need to wrap that in an installer system, we can dig out instructions as-needed | 10:49 |
| tlsa | I've de-duplicated prettytable on the branch I'm working on | 10:49 |
| kejiahu | richard_maw, I don't think we have physically access to the disk... an instrution will be appreciate | 10:51 |
| pedroalvarez | tlsa: where have you put it? | 10:52 |
| tlsa | python-core | 10:52 |
| tlsa | also updated to 0.7.2-RELEASE | 10:52 |
| richard_maw | kejiahu: what access do you have? | 10:53 |
| ssam2 | Kinnison, SotK: we've found that the current model of distbuild artifact fetching is a bit flawed, because it means the Trove needs to be able to access each worker individually | 10:53 |
| Kinnison | True | 10:54 |
| ssam2 | I believe that the proposed network config at DataCentred for the Jetson cloud would put all the workers behind one IP | 10:54 |
| ssam2 | although I've not been following closely the plans | 10:54 |
| kejiahu | richard_maw, VPN access to the node and iLO | 10:54 |
| Kinnison | that would certainly require design alteration | 10:54 |
| straycat | ssam2, I think this was originally intended to avoid requiring each worker to have write access to the trove | 10:55 |
| richard_maw | kejiahu: Does the iLO let you attach a boot disk? | 10:55 |
| Kinnison | That, and to ensure that networking firewalls were more sane (connections always went *toward* the workers for things other than what morph does to achieve a build) | 10:56 |
| kejiahu | richard_maw, I don't think so, but we can change boot preference(pxe or SSD) | 10:59 |
| SotK | OK, next question is does anyone have an idea how the same should be achieved given that the artifacts are now directory trees rather than tarballs? :) | 10:59 |
| Kinnison | via whatever synchronisation methods OSTree provides? | 11:00 |
| SotK | perhaps the Trove OSTree repo does an `ostree pull` from a remote set to the worker url | 11:00 |
| ssam2 | will `ostree pull` or `ostree push` do the job? | 11:00 |
| ssam2 | that might make sense, yeah, then the model is the samew | 11:00 |
| ssam2 | although it doesn't solve the problem of having workers behind one IP... but we could perhaps work around that separately by having the controller pull from the workers and the trove pull from the controller, as a separate task | 11:01 |
| SotK | yeah, I don't think I have time to solve that part right now :) | 11:01 |
| *** ssam2 has quit IRC | 11:06 | |
| *** ssam2 has joined #baserock | 11:20 | |
| *** ChanServ sets mode: +v ssam2 | 11:20 | |
| *** mdizzle has joined #baserock | 11:24 | |
| persia | Kinnison: How is it more sane to have the connections always towards the workers? In the case of the distbuild networks used for the cache server, it seems like we want those to have private IPs, to avoid random hosts on the internet reaching them. I worry that we may be losing something else by thinking about the problem this way. | 11:25 |
| Kinnison | persia: I can't recall the details, but I do remember it made a lot of sense at the time for the physical networks we were installing distbuild clusters into | 11:26 |
| Kinnison | persia: I'm willing to believe there's a better way | 11:26 |
| persia | I don't know. I just don't want to reverse a set of intentional decisoins without understanding them :) | 11:27 |
| Kinnison | tbf, at the time we weren't thinking of internet-connected clusters | 11:27 |
| persia | Whereas yesterday I was fully behind the idea of hiding the distbuild cluster behind a NAT, I'm suddenly unsure today. | 11:27 |
| Kinnison | so I think coming up with a design which is good for the br-ops stuff independently of previous design is possibly the best approach | 11:28 |
| straycat | if the worker gets compromised we probably don't want it to have unrestricted write access to a trove | 11:53 |
| straycat | *trove's cache | 11:53 |
| Zara | btw, is it possible to morph branch from a specific commit (if so, how)? would save me some trouble in the future! :) | 11:54 |
| straycat | Zara, i think you can just morph branch <branch> <sha> | 11:56 |
| Zara | straycat: cool, thanks :) | 11:58 |
| persia | straycat: Excellent point. | 12:00 |
| Zara | hm, just realised that 'troubleshooting' has gone under 'guides' in the wiki. I probably wouldn't look under 'guides' for troubleshooting (took me a while to find it just now; at first I thought it might have been moved under 'tips and tricks'). | 12:06 |
| petefoth | I think Troubleshooting needs to be visible in the side bar. I thought that it was. Has it been moved recently? | 12:07 |
| Zara | yeah, it's been moved. | 12:07 |
| petefoth | By <Paul@web> http://source.baserock.branchable.com/?p=source.git;a=commit;h=38e6f8a42418924550d2f0316692024b855f28a6 | 12:11 |
| petefoth | I thinhk I'll avoid getting into git-based bikeshedding about where bits of documentation should live :) | 12:12 |
| *** ssam2 has quit IRC | 12:14 | |
| Zara | yeah, we sorted this out months ago; don't really want to mess around with it again just to have it reverted. | 12:14 |
| Zara | if it bothers enough other people then someone else might change it | 12:14 |
| Zara | as for me, I know where it is now. :P | 12:15 |
| *** jonathanmaw has quit IRC | 12:15 | |
| petefoth | :) | 12:15 |
| *** ssam2 has joined #baserock | 12:26 | |
| *** ChanServ sets mode: +v ssam2 | 12:26 | |
| *** jonathanmaw has joined #baserock | 12:32 | |
| *** ssam2_ has joined #baserock | 12:35 | |
| *** radiofree has left #baserock | 12:36 | |
| pedroalvarez | argh, ebtables is broken now: http://paste.baserock.org/jopafumati | 12:59 |
| Zara | oh hey I was just about to paste about ebtables | 13:00 |
| Zara | my paste was loooooong (http://paste.baserock.org/aqugezamur) | 13:00 |
| Zara | (I was going to ask if it was to do with needing newer morph, but I'm guessing not?) | 13:01 |
| *** radiofree has joined #baserock | 13:02 | |
| pedroalvarez | could this be because of the linux-headers upgrade ? | 13:04 |
| pedroalvarez | I really don't know :/ | 13:04 |
| Zara | I was trying to build franred's openstack-v3 branch, if that helps narrow things down at all :S | 13:05 |
| pedroalvarez | so was I | 13:05 |
| Zara | :S :S | 13:06 |
| Zara | "2015-02-26 12:46:31 INFO Command failed: git cat-file blob 09792f0107a9318da809908db31f0b826017de7b:.gitmodules | 13:08 |
| Zara | fatal: Not a valid object name 09792f0107a9318da809908db31f0b826017de7b:.gitmodules | 13:08 |
| Zara | seems like it might be an important thing. | 13:08 |
| Zara | though actually it says something similar on mine for the step before, so maybe not | 13:09 |
| pedroalvarez | No, I think that's not the problem. I think morph at that point is just checking if ebtables has a .gitmoudles files | 13:10 |
| pedroalvarez | and it doesn't have any | 13:10 |
| Zara | ah, okay | 13:12 |
| pedroalvarez | ok, that file used to be in linux-api-headers, but not after the latest upgrade | 13:15 |
| pedroalvarez | http://paste.baserock.org/noleqecuqo | 13:15 |
| persia | Was the config changed? The linux API is typically fairly good about being backwards-compatible. | 13:16 |
| pedroalvarez | I'll research a bit deeper, but looks like everything from netfilter_bridge/ebt_ is there: http://paste.baserock.org/qebimokapa | 13:19 |
| persia | Interesting. It's just the one file missing. | 13:20 |
| Zara | yeah | 13:21 |
| persia | Seems to be d4da843e6fad4f278fe82b075d8e394cff05c95c | 13:22 |
| persia | So need a newer userspace, or an older kernel. | 13:23 |
| pedroalvarez | I was looking at that commit :) | 13:23 |
| persia | But that change was from 25th July 2014, making me wonder why we didn't notice previously. | 13:23 |
| pedroalvarez | the linux-api-headers chunk was using v3.8 | 13:24 |
| pedroalvarez | we have moved to v3.19 recently | 13:24 |
| pedroalvarez | and we have rebased our branches today :/ | 13:25 |
| persia | Also, that didn't get merged until d219673d8437ff1073c11d30ac496fa42b09662c | 13:25 |
| persia | Err, except that was 5 days later. Hrm. | 13:25 |
| pedroalvarez | latest ebtables commit 10 months ago.. :/ | 13:27 |
| * pedroalvarez disables ulog in ebtables | 13:48 | |
| * Zara waits to see what happens | 13:54 | |
| pedroalvarez | Zara: it builds :) | 13:55 |
| Zara | :0 | 13:55 |
| Zara | are you patching the branch, or should I just disable it manually for now (if so, how?) | 13:56 |
| pedroalvarez | Zara: branch patched | 13:57 |
| Zara | =D | 13:57 |
| pedroalvarez | I'll investigate now if ebtables is still needed for libvirt | 13:57 |
| kejiahu | richard_maw, have you managed to find instructions about deploy trove to M400 please? | 13:59 |
| richard_maw | http://wiki.baserock.org/guides/deploy-to-hardware/ is the closest | 14:05 |
| richard_maw | Is there a DHCP server already running in the private network you join via VPN? | 14:06 |
| Zara | build failed at python-memcached this time | 14:07 |
| SotK | whats the error? | 14:07 |
| Zara | ah, it's setuptools again | 14:08 |
| pedroalvarez | Zara, SotK: That one is easy :) | 14:08 |
| Zara | (http://paste.baserock.org/koramemole) | 14:09 |
| richard_maw | kejiahu: if not you might get away with joining it and deploying with `PXEBOOT_MODE: spawn-novlan` | 14:09 |
| pedroalvarez | Zara: fixed | 14:10 |
| Zara | :D | 14:10 |
| kejiahu | richard_maw, thanks | 14:10 |
| richard_maw | kejiahu: you will have to be careful about PXEBOOT_DEPLOYER_INTERFACE though. The dhcp server that spawn-novlan spawns will bind to that interface, so any DHCP requests that come in on that interface will be handled. | 14:12 |
| richard_maw | kejiahu: I don't recall the details about how VPNs work, but if connections to your local, physical network, and the remote network over the VPN are on the same interface, then you can bring down your local network. | 14:15 |
| richard_maw | if after you connect to the VPN you have a new entry in `ip link` then you should be able to connect that into your virtual machine and deploy over that | 14:17 |
| kejiahu | richard_maw, can't I build and deploy from a node within the same subnet of target node? | 14:18 |
| kejiahu | richard_maw, as we seems have plant of M400 to use | 14:18 |
| ssam2_ | FYI: I'm thinking of doing a baserock 15.09 release tomorrow, any thoughts? | 14:19 |
| ssam2_ | didn't do one last friday because there were still a bunch of bugs | 14:19 |
| pedroalvarez | that would be great IMO | 14:19 |
| ssam2_ | and in fact someone still needs to get a patch sent and merged for http://paste.baserock.org/ibuqiyucup (morph builds systems that extlinux can't boot right now) | 14:20 |
| ssam2_ | I'll look at doing that later today | 14:20 |
| pedroalvarez | IIRC this was a workaround and not a fix? Being the fix a syslinux upgrade? | 14:21 |
| * pedroalvarez is not sure | 14:21 | |
| ssam2_ | it's a workaround | 14:21 |
| ssam2_ | but i'm not sure if latest syslinux actually supports the new btrfs stuff yet | 14:21 |
| * tiagogomes_ wrecked the network of his machine with PXEBOOT_DEPLOYER_INTERFACE | 14:22 | |
| richard_maw | kejiahu: you didn't mention that you already had a foothold in the network. You could deploy from a node already in there. | 14:27 |
| kejiahu | richard_maw, ha. my apologize.. | 14:32 |
| richard_maw | I'm just a little worried that you might already have a DHCP server in there. Do you need to statically assign IP addresses to the nodes or your client when you connect to the VPN? | 14:34 |
| tiagogomes_ | heh, I can't build things anymore: http://paste.baserock.org/dopekuzewi | 14:34 |
| tiagogomes_ | it was working before | 14:34 |
| pedroalvarez | tiagogomes_: I think is a known bug | 14:35 |
| tiagogomes_ | but it was working!! | 14:35 |
| tiagogomes_ | is there a known solution? | 14:35 |
| pedroalvarez | I think the fix was merged in morph | 14:35 |
| pedroalvarez | I may be wrong | 14:35 |
| kejiahu | richard_maw, I think there is a DHCP server there already | 14:36 |
| Zara | pedroalvarez: setuptools strikes again! mod_wsgi-metrics (my step 206/413) | 14:37 |
| pedroalvarez | Zara: already fixed :) | 14:37 |
| Zara | bahhh, I must have cloned between the last fix and that one | 14:37 |
| pedroalvarez | tiagogomes_: this sha1 of morph has the fix: f5163dd418e342fe6e5fb18625828076130a5e57 | 14:37 |
| pedroalvarez | Zara: note you don't have to remove and clone again | 14:38 |
| pedroalvarez | `git pull` should be enough | 14:38 |
| tiagogomes_ | pedroalvarez ta, I'm still curious why it just stopped working | 14:38 |
| richard_maw | kejiahu: right, that means you need to set up a machine on that network to have a tftp and nfs server, and to configure the DHCP server to direct net-boot requests to the other server | 14:38 |
| pedroalvarez | tiagogomes_: check if latest version works, and if that was the problem then you can ask Sam (who did the fix :) | 14:39 |
| Zara | pedroalvarez: ah, I'd been removing and 'morph branch'ing. | 14:39 |
| pedroalvarez | tiagogomes_: haha! I've just hit the same bug | 14:40 |
| kejiahu | richard_maw, yes, that's what tiago is working on. I will check with him when necessary | 14:40 |
| tiagogomes_ | it is like a virus, it spreading | 14:40 |
| pedroalvarez | I'm using 74f60a7ed286dd88e24539d46b9a86147a8e78b5 | 14:40 |
| pedroalvarez | erm.. morph master doesn't fix it | 14:41 |
| tiagogomes_ | perhaps this is a problem with the git query service on the trove no? | 14:43 |
| * tiagogomes_ tries with --no-git-update | 14:43 | |
| SotK | pedroalvarez: can you paste your morph log somewhere? | 14:44 |
| tiagogomes_ | kejiahu we already have tftp, nfs and dhcp servers configured | 14:44 |
| Zara | pedroalvarez: xstatic also faces the setuptools foe | 14:45 |
| tiagogomes_ | it didn't work, :| | 14:45 |
| straycat | what is going on here? everything should get setuptools | 14:45 |
| SotK | setuptools was moved to python-core from core and some/all dependencies weren't updated | 14:46 |
| SotK | s/dependencies/stratum build-depends/ | 14:46 |
| tiagogomes_ | now it is working, but it is building everything from scratch :'( | 14:47 |
| pedroalvarez | SotK: http://paste.baserock.org/nahijaluja | 14:47 |
| * SotK is confused as to why that happened :/ | 14:50 | |
| pedroalvarez | urghh! it's building a different sha1 and not my current sha1 | 14:50 |
| pedroalvarez | just because I have my git repository clean | 14:51 |
| pedroalvarez | and I'm building a different branch as the one I checked out | 14:51 |
| pedroalvarez | :/ | 14:51 |
| * pedroalvarez does an sdupid modification on its definitions repo and everything builds again | 14:52 | |
| persia | Can we fix morph to not try to outsmart developers so much? | 14:52 |
| * Zara refreshes g.b.o in expectation of xstatic fix | 14:54 | |
| * pedroalvarez fixes xstatic for Zara | 14:54 | |
| Zara | and you! if we're still building the same branch. :P | 14:54 |
| Zara | thanks :) | 14:55 |
| pedroalvarez | np :) | 14:55 |
| franred | yeah, thanks pedroalvarez | 14:57 |
| pedroalvarez | that concrete fix should be merged in master though | 14:58 |
| franred | pedroalvarez, I think the most of them | 14:58 |
| pedroalvarez | i don't know the others, but xstatic is in master already | 14:59 |
| franred | ebtables, python-memcached, apache and xstatic are in master already | 14:59 |
| pedroalvarez | true | 15:00 |
| franred | the setuptools change is a headache for openstack guys because we use a lot of python packages in different strata which almost no-one uses (no in masons I think) | 15:02 |
| straycat | so each of those strata just need to build-depend on python-core | 15:06 |
| straycat | or build-depend on some common thing that build-depends on python-core of course | 15:06 |
| pedroalvarez | yup | 15:08 |
| franred | have we ever considered to create a way to specify to build some artifacts rather than download them? (Im thinking that in slow connections build a small python package might be faster than create a connection and download its cached artifact but other like linux/qemu... you would like to download it) | 15:26 |
| ssam2_ | quite complex to write code to work out which will be faster | 15:28 |
| ssam2_ | it'd be easier to let humans write rules like 'always build chunks in this stratum instead of downloading' (might make sense for python-core etc) | 15:29 |
| straycat | yeah that might be quite cool | 15:30 |
| SotK | I would like this | 15:30 |
| franred | ssam2_, yes, nothing very wise, just a way to say this chunk/stratum has to be built always and not use the cache | 15:35 |
| richard_maw | couldn't you do that by filtering artifact uploads to the cache server? | 15:40 |
| straycat | i think there's an argument that the ideal choice varies with geography/network connectivity | 15:40 |
| franred | richard_maw, your suggestion is to filter them in the mason to not upload them so you will always force the people to build them? | 15:44 |
| richard_maw | something like that, yes | 15:45 |
| *** petefoth has quit IRC | 15:46 | |
| pedroalvarez | if we move to ostree artifacts, when all the artifacts are needed to deploy a system, then we won't be able to deploy a system from cache.baserock.org without building it | 15:47 |
| pedroalvarez | also, cache.baserock.org is the shared artifact server of mason, so if a chunk is not there mason won't be able to build chunks that depend on it | 15:49 |
| * pedroalvarez has done a better workaround for ebtables | 15:49 | |
| pedroalvarez | I will submit the patch upstream :) | 15:49 |
| franred | pedroalvarez, cool :) | 15:50 |
| franred | pedroalvarez, you are right, also if we force to build a chunk from source and not use the cache artifact it implies that its dependencies have to be built | 15:50 |
| franred | immm | 15:51 |
| franred | ummm even | 15:51 |
| pedroalvarez | franred: no, that's not true | 15:51 |
| straycat | *bandwidth | 15:52 |
| pedroalvarez | build and download at the same time and whatever finishes first? :P | 15:52 |
| franred | pedroalvarez, if chunk b depends on chunk a and a is built does not implies that b is going to be built too? | 15:53 |
| pedroalvarez | if you build A or you download A, it has to be the same | 15:54 |
| pedroalvarez | so dependencies can still be downloaded | 15:54 |
| franred | yeah, that's true | 15:54 |
| tiagogomes_ | why x86 kernels are not versioned, and ARM kernels are? e.g vmlinux-3.19-rc5 | 15:55 |
| *** jonathanmaw has quit IRC | 16:02 | |
| ssam2_ | no idea | 16:11 |
| ssam2_ | i'm still getting 'setuptools' errors with master of definitions (38bc8b124a2c15abde91c7c263a833459071efa5) | 16:19 |
| persia | I don't like anything being built locally if it is available in cache, even though this has caused me to take multiple days building systems in the past because nothing was built locally and network was bad. | 16:19 |
| ssam2_ | in chunk markupsafe | 16:20 |
| Zara | ...can anyone confirm that the openstack-cluster.morph, deployed and used as the basis for a vm in virt-manager, actually boots? I'm getting the same failure to boot as last week. | 16:20 |
| persia | Essentially, as soon as I have multiple local builds, I don't trust that I have the same thing, because they aren't bit-identical. | 16:20 |
| ssam2_ | Zara: latest morph makes systems that don't boot | 16:20 |
| ssam2_ | patch http://paste.baserock.org/ibuqiyucup will fix it | 16:20 |
| persia | I'm willing to trust the cache-key generation logic to know when I need different binaries, but I'm not happy about building things differently in different places, and trusting the test results will match. | 16:21 |
| franred | ssam2_, pedroalvarez has patches for it but they are applied to openstack-v3 | 16:21 |
| ssam2_ | pedroalvarez: do you have time to send them for review for merge into masteR? | 16:21 |
| Zara | ssam2_: okay, I'm not actually using latest morph right now, but the morph that came on this system | 16:21 |
| ssam2_ | in return I'll send a patch for this horrible morph bug | 16:21 |
| pedroalvarez | ssam2_: I do have time for that | 16:21 |
| Zara | does anyone have a commit ref handy for a version of morph I can use that builds systems that boot? | 16:23 |
| ssam2_ | it's not Morph that changed to trigger this problem. it's the upgrade of btrfs-progs that broke things | 16:24 |
| ssam2_ | so the only fix is to apply the patch I linked to for now, or downgrade your OS to one that has btrfs-progs older than v3.18.2 | 16:25 |
| Zara | ah, okay | 16:25 |
| Zara | that would explain why I was able to build a devel system but not this one :) | 16:26 |
| ssam2_ | morph.git branch sam/disable-new-btrfs-features sent for review, i'd appreciate if someone who was hit by this bug can test it for me | 16:46 |
| *** zoli__ has joined #baserock | 16:46 | |
| Zara | hi ssam2_; I've patched my morph but I'm not sure how it interacts with the build process-- do I need to get rid of something and rebuild, or just redeploy? | 16:50 |
| ssam2_ | just redeploy | 16:50 |
| Zara | cool, thanks :) | 16:50 |
| ssam2_ | to be clear, the branch is different from the patch I linked to earlier | 16:50 |
| ssam2_ | could you try the branch rather than the patch? the branch is the thing that would actually get merged to morph.git | 16:51 |
| Zara | oh, okay, I can try the branch-- I'm not using latest morph at the moment, so just checking that won't cause a problem? | 16:51 |
| ssam2_ | the branch is on top of the latest 'master' of Morph | 16:54 |
| ssam2_ | if your devel system is new enough to have pylru then it shouldn't cause any issue | 16:54 |
| ssam2_ | if it doesn't have pylru you'll need to clone it, as described in http://wiki.baserock.org/using-latest-morph/. | 16:54 |
| ssam2_ | anyway, if you don't have pylru you'll find out soon enough :) | 16:55 |
| Zara | I switched back and forth a bit in case morph was causing my errors earlier; should have all the bits and pieces lying around! | 16:56 |
| *** a1exhughe5 has quit IRC | 17:01 | |
| Zara | can confirm that dear little tarquin booted. there's some strangeness (eg: I couldn't reboot at first), but that might just be unique to this vm, and I just don't know about it because I haven't booted this vm before | 17:32 |
| Zara | either way, better than not booting. | 17:32 |
| *** Krin has quit IRC | 17:33 | |
| ssam2_ | great, thanks! | 17:33 |
| ssam2_ | mason-x86-32.baserock.org is now building stuff again, i've upgraded it to get the sam/sourceresolver-fixes branch of morph | 17:34 |
| robtaylor | mauricemoss_, rdale: do i understand correctly you've built a minimal system with musl? o_O! | 17:49 |
| mauricemoss_ | robtaylor: rdale did built some parts with musl, but not a full system AFAIK. I just verified a small patch to make from him. | 17:52 |
| robtaylor | ahh | 17:55 |
| robtaylor | :) | 17:55 |
| *** bashrc has quit IRC | 17:56 | |
| *** mdizzle has quit IRC | 18:00 | |
| *** CTtpollard has quit IRC | 18:04 | |
| rdale | i can try and build a minimal musl based system though, as the stratum is done | 18:05 |
| *** tiagogomes_ has quit IRC | 18:07 | |
| *** tiagogomes_ has joined #baserock | 18:08 | |
| *** rdale has quit IRC | 18:23 | |
| *** gfinney_ has quit IRC | 18:33 | |
| *** ssam2_ has quit IRC | 18:45 | |
| *** ssam2 has quit IRC | 18:46 | |
| *** jmac has joined #baserock | 18:46 | |
| *** jmac is now known as jmacs | 18:47 | |
| *** gary_perkins has quit IRC | 18:55 | |
| *** zoli__ has quit IRC | 21:06 | |
| *** zoli__ has joined #baserock | 23:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!