*** ridgerunner [~robjones@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 240 seconds] | 00:03 | |
*** ridgerunner [~robjones@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:05 | |
*** cyndis [cyndis@lakka.kapsi.fi] has quit [Ping timeout: 272 seconds] | 00:45 | |
*** cyndis [cyndis@lakka.kapsi.fi] has joined #baserock | 00:46 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 05:51 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 05:51 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:51 | |
*** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 240 seconds] | 05:58 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [] | 06:24 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:25 | |
*** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 06:44 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:06 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:10 | |
*** elevenarms_ [~elevenarm@c-69-181-189-77.hsd1.ca.comcast.net] has joined #baserock | 08:23 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:25 | |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:41 | |
*** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has quit [Ping timeout: 250 seconds] | 08:54 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
*** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has joined #baserock | 09:05 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:10 | |
paulsher1ood | straycat: there are no commands - it's just ybd relative/path/to/definition. i recommend using the check.sh script to drive it since by default ybd leaves staging areas around. check.sh clears up | 09:16 |
---|---|---|
paulsher1ood | straycat: it's far from a prototype of a new morph, so far. doesn't actually build anything. i'm just trying to iron out the overall logic at this point | 09:17 |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:23 | |
Mode #baserock +v ssam2 by ChanServ | 09:23 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:31 | |
straycat | jjardon, If you want to move setuptools out of core that's fine by me in a separate series, as I said on the list we need to find out how many things above core build using setuptools before doing anything, I'm quite busy at the moment and moving setuptools out of core isn't important for what I'm trying to get done. | 09:40 |
straycat | paulsher1ood, yes I managed to get it to 'build' definitions in the end | 09:41 |
jjardon | straycat: yeah, sure; it was only a suggestion. But still i think it would be less confusing if you can change the name of the new stratum to something different to 'python' | 09:51 |
straycat | jjardon, ssam2's already noted that and yes I agree | 09:52 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 09:57 | |
straycat | ssam2, the python-setuptools-bitbucket repo is the current setuptools | 10:01 |
straycat | i chose not to link to the bugtracker because i'll sort it out if upstream merge my stuff | 10:01 |
ssam2 | straycat: I don't understand that reasoning for not linking to the bug tracker. What if you're be super busy with something else for a while and someone else on the Baserock team needs to update setuptools ? | 10:05 |
ssam2 | -be | 10:05 |
ssam2 | re. python-setuptools-bitbucket, is there any reason for not updating the existing python-setuptools.lorry? I guess it depends whether they share any history or not | 10:05 |
straycat | there are two versions of setuptools | 10:06 |
ssam2 | right :( setuptools got super-forked | 10:06 |
straycat | the "main" hg version on pypa, and a 0.6 branch in svn 'sandbox' | 10:06 |
straycat | to be honest any details i've ommitted are more to do with me being very busy | 10:07 |
straycat | *omitted | 10:07 |
straycat | well, in part, i don't have time to worry too much about commit message right now, is what i'm saying | 10:08 |
straycat | and since i have 2 +1s now, i'm going to merge with the name change you suggest | 10:08 |
ssam2 | ok. I think you're creating extra work for future integrators who'll need to go digging to find out the things you've just told me. | 10:09 |
ssam2 | so I'd appreciate if you could put the info in the commit message | 10:09 |
* straycat nods | 10:12 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:13 | |
radiofree | subprocess.call = ([mkdir.....) | 10:14 |
radiofree | no wonder everything was failing after that | 10:14 |
jmacs | Hah | 10:15 |
straycat | radiofree, weren't you using check_call? Am I missing some detail about how that works? | 10:16 |
franred | or better use os.mkdir | 10:18 |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:41 | |
richard_maw | radiofree: function call got translated to an assignment between brain and keyboard? | 10:41 |
radiofree | straycat: it was actually another .call() that was failing, for the reason richard_maw described! | 10:45 |
radiofree | franred: thanks, i'll use that instead | 10:45 |
radiofree | the default path for extlinux.conf files seems to be /extlinux/extlinux.conf rather than /extlinux.conf | 10:46 |
* radiofree will send a patch that tries both of those directories | 10:47 | |
straycat | radiofree, ahh :) | 10:48 |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 10:58 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:05 | |
straycat | jjardon, In fact now that I've had a little more thought, regardless of how many things above core require setuptools to build there's always the possibility that somebody will want something in core that requires setuptools to build, setuptools being an extension of distutils makes me feel that it rightfully belongs with cpython. | 11:06 |
pedroalvarez | straycat: I'm slightly worried about pip being removed of the webtools stratum and not being added to the systems that are using it. I wonder if pip was being used in any of them | 11:34 |
straycat | It would be the web system and the gitlab system | 11:36 |
richard_maw | radiofree: IIRC it looks for /extlinux.conf /boot/extlinux.conf and /boot/extlinux/extlinux.conf | 11:36 |
straycat | I don't know much about those systems or whether they need pip | 11:36 |
straycat | if they do then they should add the python-tools stratum | 11:36 |
pedroalvarez | it's ok | 11:37 |
pedroalvarez | I just wanted to raise the point | 11:37 |
radiofree | richard_maw: yes i thought that too | 11:39 |
radiofree | richard_maw: however in upstream it's now extlinux/extlinux.conf | 11:39 |
radiofree | http://git.denx.de/?p=u-boot.git;a=blob;f=include/config_distro_bootcmd.h;h=be616e8bfd0e0578d54c0414e29599885ada17e8;hb=HEAD#l168 | 11:39 |
richard_maw | oh, u-boot, I thought you were talking about syslinux | 11:39 |
*** aananth [~caananth@74.112.167.117] has joined #baserock | 11:44 | |
aananth | I am able to build a new jetson image and wandboard image from jetson board which is configured to use vtsc-trove. The build times are considerably faster. Great support team! | 11:46 |
*** aananth [~caananth@74.112.167.117] has quit [Client Quit] | 11:47 | |
pedroalvarez | aananth: that is really good to hear :) | 11:53 |
robtaylor | woohoo! :) | 11:59 |
radiofree | patches to boot off separate partition sent! | 12:36 |
paulsher1ood | radiofree: i'd like to test it... | 12:45 |
paulsher1ood | i just need to establish how i update tbdiff in my current machine | 12:45 |
paulsher1ood | do i need to cycle into that, then test something from there? | 12:45 |
radiofree | paulsher1ood: you don't need to update it in your current machine | 12:46 |
radiofree | cycle a system with that version of tbdiff in it | 12:46 |
paulsher1ood | right | 12:47 |
radiofree | the version of system-version-manager in the system you are deploying gets used, not the hosts | 12:47 |
pedroalvarez | indeed, the upgrade uses the tbdiff of the system being deployed | 12:47 |
radiofree | which is pretty neat | 12:47 |
paulsher1ood | yup | 12:47 |
franred | jjardon, pedroalvarez, looks like gstreamer compiles with my patch in common when checking bison - maybe is time to polish it and send it for review | 13:01 |
pedroalvarez | franred: let's see if they like it | 13:02 |
franred | pedroalvarez, I imagine I need to file a bug, add the use case and send the patch in the bug report | 13:02 |
pedroalvarez | franred: hm.. I was going to point you to : http://gstreamer.freedesktop.org/wiki/SubmittingPatches | 13:06 |
pedroalvarez | franred: but yes, you are right. Here says: file a new bug and then attach the patch to the bug (http://gstreamer.freedesktop.org/dev/) | 13:07 |
franred | ummm, looks like ssam2 sent a patch long time ago about this: https://bugzilla.gnome.org/show_bug.cgi?id=728946 | 13:14 |
*** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has quit [Ping timeout: 250 seconds] | 13:17 | |
*** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has joined #baserock | 13:22 | |
pedroalvarez | yay! they said that they will merge it :) | 13:29 |
franred | \o/ | 13:29 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:35 | |
pedroalvarez | ssam2: congratulations for your contribution to gstreamer: http://cgit.freedesktop.org/gstreamer/common/log/?qt=author&q=Thursfield | 13:38 |
straycat | my import of python-keystoneclient fails because of some alternative tagging scheme in some of the repos (r122 rather than 1.2.2) :/ | 13:40 |
franred | straycat? | 13:42 |
straycat | the tool decided to lorry from a hg repo on code.google.com, the import tool doesn't recognise the tags in that repo | 13:47 |
straycat | don't think there's much we can do about that really | 13:47 |
straycat | So we need a very good error message that explains exactly why the ref couldn't be found | 13:48 |
pedroalvarez | Right, so mason has been redeployed, and http://cache.baserock.org/ has been created | 13:55 |
pedroalvarez | for now is the old baserock-clone, with a DNS | 13:56 |
ssam2 | straycat: i'm going to change the import tool so that it doesn't stick version numbers on the end of the chunk names by default | 14:10 |
ssam2 | i've been meaning to do this for ages and thinking it'd be simple but having come to do it I l realised that it's actually the *.to_chunk programs that need to be changed to make this happen | 14:10 |
straycat | oh? | 14:10 |
ssam2 | it's inconsistent with the existing Baserock reference system definitions otherwise | 14:11 |
ssam2 | I'm finding when importing Rails 'master' that there are two versions of some components in the build graph, so I guess i'm about to find out what happens when there are conflicts like that ;) | 14:11 |
ssam2 | it kind of sucks that we lose the upstream version number in this scheme, though | 14:13 |
straycat | hmm | 14:14 |
paulsher1ood | ssam2: why not keep them? | 14:15 |
paulsher1ood | foo|version would be better than n definitions of foo imo | 14:15 |
* persia agrees | 14:16 | |
* richard_maw is going to leave that discussion alone for now | 14:16 | |
ssam2 | foo|version would be better where there are more than one | 14:16 |
ssam2 | but is it going to be common to want multiple versions of every RubyGem in the universe in Baserock ? | 14:16 |
straycat | i'm quite confused, two versions of one thing will conflict, unless you start messing around with paths. | 14:17 |
ssam2 | if there are two versions the tool will have to detect that and append a version number to at least one of them | 14:17 |
straycat | in certain situtations python can manipulate sys.path to import the 'right' thing if it has enough information to do that | 14:17 |
ssam2 | RubyGems are parallel-installable | 14:17 |
ssam2 | I'm worrying only about what's in definitions.git here | 14:18 |
straycat | oh okay | 14:18 |
paulsher1ood | ssam2: sadly it is quite common, yes. to the extent that devs have a couple of options to allow multiple stacks to coexist (rbenv, rvm) | 14:18 |
ssam2 | hmm, I suppose so | 14:18 |
ssam2 | well it's much less work to keep things working as they do now | 14:18 |
ssam2 | I expected everyone to be dismayed by having version numbers in the names of all the chunks, to be honest! | 14:19 |
* paulsher1ood loves how organisations that aren't involved in foo can leverage foo by spouting about 'The future of foo' | 14:19 | |
straycat | well, I've not been doing it for python | 14:19 |
paulsher1ood | straycat: not all the chunks. just the ones where we have more than one | 14:20 |
paulsher1ood | version | 14:20 |
ssam2 | oh, right. That's the thing that's difficult. | 14:20 |
straycat | it's not possible to import two chunks with different versions with the python exts | 14:20 |
ssam2 | straycat: right. | 14:21 |
doffm_ | jmacs: How is the ceph stuff going? Did I help yesterday? | 14:21 |
doffm_ is now known as doffm | 14:21 | |
straycat | ssam2, oh, well, it might be, an import isn't aware of what's currently in definitions | 14:22 |
paulsher1ood | ssam2: what's the difficulty? we have lots of unique chunks, no versioning need. we encounter a need to have another version of foo - that one gets imported/added as foo|version ? | 14:23 |
jmacs | doffm: I wasn't able to figure it out unfortunately; I've written up what I did at http://wiki.baserock.org/misc-docs/deploy-ceph-with-baserock/ and I'm going to shelve that for now. | 14:23 |
ssam2 | paulshe1ood: the difficulty is explaining what you just said in terms that a computer can understand :) | 14:24 |
paulsher1ood | really? | 14:24 |
ssam2 | it may not be so hard. I'm working on it now so we'll find out soon enough | 14:24 |
straycat | if ruby gems are parallel installable then it seems reasonable to put version numbers in the names of gems | 14:27 |
straycat | so I guess I was suggesting making the extension control whether or not version numbers were appended | 14:47 |
ssam2 | right. Currently it seems the .to_chunk extension decides on the name of the chunk and baserock-import decides on the filename of the morphology | 14:48 |
* straycat nods | 14:48 | |
ssam2 | currently baserock-import hardcodes the name 'strata/$stratumname/$chunkname-$version.morph' | 14:48 |
paulsher1ood | what was the umount magic if deploy to self runs out of space? | 15:04 |
* paulsher1ood works it out ... umount /tmp/tmp.whatever is full | 15:06 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 15:38 | |
persia | In http://wiki.baserock.org/guides/deploy-trove-to-openstack/, should one be creating admin.key as well (as admin.key.pub is referenced later)? | 15:50 |
paulsher1ood | radiofree: ok i've cycled into your tbdiff branch (after some other priorities...) what shall i test ? | 15:51 |
pedroalvarez | persia: if you want to attach a volume to the trove I don't recommend you to follow those instructions | 15:54 |
persia | Ah, OK. And if I don't attach a volume, then I lose all my trove data when my instance dies? | 15:54 |
pedroalvarez | yes | 15:55 |
persia | That makes sense. | 15:55 |
persia | If I am using those instructions, should cloud-config.sh create an admin key? | 15:55 |
pedroalvarez | persia: it depends if you want to create a new ssh key for the admin user, or use yours | 15:56 |
persia | Aha. That makes sense. I'll create a new one for play: I think adding one means I have to do fussy things to instantiate, rather than it just working. | 15:57 |
persia | (and I have no idea what "admin" means, nor do I see it documented anywhere, so I imagine I can safely do without access to the key) | 15:58 |
persia | But I think the wiki probably should be clearer about this. I fear that if the instructions are followed blindly, the user will encounter an error. | 15:58 |
pedroalvarez | yeah, I had documented in multiple ways before | 15:59 |
pedroalvarez | but I think I failed to make them easy to understand | 15:59 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:01 | |
persia | heh | 16:01 |
pedroalvarez | this admin is going to be the gitano admin, the one that can create/destroy/modify users/repos/etc.. | 16:02 |
pedroalvarez | but if you have root access, you can do the same from the git user :) | 16:02 |
persia | That needs some documentation :) | 16:02 |
persia | And to confirm, once I have a trove, I just add TROVE: 1.2.3.4 (except with a real IP) to morph.conf? | 16:03 |
pedroalvarez | that is the TROVE_HOST | 16:06 |
pedroalvarez | you have to add also the TROVE_ID | 16:07 |
pedroalvarez | persia: btw, just found this video: https://www.youtube.com/watch?v=JmH4cCjs5-M | 16:07 |
persia | So add "TROVE_HOST" and "TROVE_ID"? | 16:07 |
* persia refuses to watch any videos over a mobile data connection | 16:07 | |
pedroalvarez | :) | 16:08 |
persia | Is it safe for both "TROVE_HOST" and "TROVE_ID" to be bare IP addresses? | 16:08 |
pedroalvarez | persia: you have to use the same values that you used in TROVE_ID | 16:09 |
pedroalvarez | I mean | 16:09 |
pedroalvarez | *... that you used when deploying the trove | 16:09 |
pedroalvarez | (my brain left my head for some seconds) | 16:09 |
persia | What if there is no working DNS? | 16:09 |
pedroalvarez | then TROVE_HOST is the IP | 16:09 |
persia | And this has to be listed in the initial configuration? | 16:10 |
* persia believes this incompatible with launching from nova | 16:10 | |
pedroalvarez | and TROVE_ID is "my-trove-foo" or whatever | 16:10 |
radiofree | paulsher1ood: that system-version-manager still works | 16:10 |
pedroalvarez | and I'm not sure about TROVE_HOSTNAME | 16:10 |
persia | Right. Trove is still broken. When can we not have troves anymore? :) | 16:10 |
pedroalvarez | persia: why do you think that is broken? | 16:12 |
persia | pedroalvarez: Because it means I need to know the IP before I run the nova command to launch the trove, but cannot assign an IP until after the instance is up, leading to a chicken-and-egg condition, especially in highly-used environments where I can't expect a recently allocated IP to remain mine while nova launches (because someone else could use it). | 16:13 |
pedroalvarez | true | 16:14 |
persia | The result of this is it is impossible to configure a trove reliably | 16:14 |
pedroalvarez | the trove will work without the right ip, but then the urls to clone repos will be wrong | 16:14 |
persia | So morph will break? | 16:14 |
pedroalvarez | nope | 16:15 |
pedroalvarez | so it's not very broken :) | 16:15 |
SotK | the clone urls on cgit are the ones which will be wrong I think | 16:15 |
persia | If the urls to clone repos are wrong, how will morph clone git repos? | 16:15 |
persia | Oh, that's not so bad. Still, something to make go away someday :) | 16:15 |
pedroalvarez | persia: morph will translate "upsgream:" and "baserock:" usiing your morph.conf | 16:16 |
persia | Ah, that is excellent design. Separation of concerns :) | 16:16 |
pedroalvarez | persia: sorry for the confusion before. The trove only needs TROVE_ID to work. TROVE_HOST doesn't even exist. | 16:19 |
pedroalvarez | TROVE_HOSTNAME exists, but is optional only for cgit to show the clone urls | 16:19 |
pedroalvarez | everything else will be fine | 16:19 |
persia | Ah, good :) I'm glad things can work. | 16:19 |
* persia was a bit confused, because things seemed sane previously | 16:20 | |
* Kinnison notes you can also set TROVE_HOSTNAME to the IP address to be used to talk to the trove | 16:30 | |
pedroalvarez | yeah, but at the moment that he is configuring TROVE_HOSTNAME he doesn't know the real IP | 16:31 |
Kinnison | aah :-( | 16:31 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:34 | |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 16:40 | |
persia | Kinnison: More specifically, I *cannot* know the IP at the time I configure it, which means whether it is a hostname or IP, it will always be wrong. | 16:46 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 16:50 | |
Kinnison | aah | 17:09 |
rdale | if branch 'baserock/morph' already exists, does that mean i can't push a 'baserock/morph/1.4.6' branch? | 17:12 |
Kinnison | yes | 17:12 |
Kinnison | Git doesn't allow foo and foo/bar to exist :-( | 17:13 |
rdale | ah ok thanks | 17:13 |
richard_maw | because you can't have a directory entry be both a directory and a file | 17:13 |
Kinnison | Indeed | 17:13 |
pedroalvarez | rdale: baserock/1.4.6 can be a good name | 17:14 |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:14 | |
rdale | ok, i'll use that. i am a bit unsure of branch naming conventions, use of 'unpetrify-morph' and so on | 17:15 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:27 | |
persia | So, I've set up a trove, and ${IP}/lc_status.html reports "New jobs are allowed" and "There are no jobs running at this time". What ought happen to start the mirroring process? | 17:40 |
straycat | iirc it spends a little while creating the repos to lorry into | 17:42 |
straycat | before it starts lorrying | 17:42 |
persia | OK. So I shouldn't worry? | 17:43 |
straycat | journalctl should help you see what's going on | 17:43 |
persia | Grr. I seem to have lost the ability to insert keystrokes. I'll check later. Thanks. | 17:44 |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:59 | |
persia | So, my trove still isn't proxying. Testing locally, it seems that I need to set a proxy server. Where in the trove and/or lorry configuration do I do that? | 18:00 |
ssam2 | persia: adding a proxy.conf is described here: http://wiki.baserock.org/guides/configuring-a-trove/ | 18:01 |
ssam2 | I found it quite painful when I tried to do it | 18:02 |
* persia tries | 18:02 | |
paulsher1ood | but at least one person has achieved it, on another continent... | 18:02 |
pedroalvarez | :) | 18:03 |
persia | Where is "local-config/lorries.git"? | 18:04 |
franred | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/ | 18:04 |
franred | persia ^^ | 18:04 |
Kinnison | persia: It will be in your trove prefix | 18:04 |
ssam2 | persia: the first section 'Accessing the local-config repositories' should cover that | 18:04 |
persia | What is a "trove prefix"? | 18:04 |
pedroalvarez | ssh://git@{IP}/{TROVE_ID}/local-config/lorries.gi | 18:05 |
paulsher1ood | ct-mcr-1 for example | 18:05 |
paulsher1ood | same as trove_id | 18:05 |
persia | Where am I supposed to run these commands? | 18:05 |
paulsher1ood | all references to prefix should have been switched to trove_id i believe | 18:05 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:05 | |
ssam2 | persia: on a machine which can SSH to the Trove, and has the trove-admin private key available | 18:05 |
paulsher1ood | he is in a place with no ssh i fear | 18:06 |
* persia will see if such a machine can be made to exist | 18:06 | |
* persia suspects not | 18:06 | |
paulsher1ood | persia: could you ssh in from the trove itself? | 18:06 |
paulsher1ood | i know it's ridiculous | 18:06 |
ssam2 | that's a new problem to me. | 18:06 |
ssam2 | how will users of the Trove access it in an authenticated way? | 18:06 |
ssam2 | we apparently have HTTPS support, but I've never tried to use it | 18:07 |
persia | If this requires ssh, they won't. | 18:07 |
persia | Does this make trove not work? | 18:07 |
ssam2 | all the Troves we've deployed so far have required SSH for push access, so for current values of trove, I think so | 18:07 |
persia | paulsher1ood: Actually, that works. heh. Now I wonder if it is useful. | 18:08 |
persia | ssam2: Ah, OK. Thanks. | 18:08 |
ssam2 | as I said, there is HTTPS support which I don't think I've ever used | 18:08 |
* paulsher1ood wonders if users can push via https? | 18:09 | |
ssam2 | that's the plan, I think | 18:10 |
ssam2 | I don't know much about it, I'm afraid | 18:11 |
radiofree | gitano supports https push, we use it quite often | 18:12 |
radiofree | don't know if gbo is setup for that though | 18:13 |
paulsher1ood | radiofree: that should be fine and give some confidence for persia's purposes | 18:14 |
persia | Needs investigation, I frequently find fun pockets of odd infrastructure :) | 18:15 |
persia | So, I found a way to ssh to the trove: what sort of keys do I want to use to do so? How do I know the name of the "adminuser" as specified on that page? | 18:16 |
pedroalvarez | persia: do you remember the admin.key? | 18:17 |
persia | My trove has an /etc/trove/admin.key : that one? | 18:17 |
pedroalvarez | using that key you can do gitano administration, and clone the lorries.git repo | 18:18 |
persia | OK. | 18:18 |
pedroalvarez | (I normally avoid this using the git user: `su git; cd; git clone localhost/{TROVE_ID}/local_config/lorries.git` | 18:19 |
pedroalvarez | ) | 18:19 |
pedroalvarez | this is not documented because it shouldn't be done this way | 18:20 |
pedroalvarez | I tink I'm missing ssh:// in localhost | 18:21 |
persia | It should stay undocumented, but this means of configuration makes too many assumptions about infrastructure. | 18:21 |
persia | So, again, how do I determine the right value for "adminuser"? | 18:22 |
persia | Is that TROVE_ADMIN_USER from the configuration? | 18:22 |
persia | (this is not an actual user as far as the system is concerned) | 18:22 |
pedroalvarez | right | 18:23 |
persia | Cool. That works. | 18:23 |
pedroalvarez | `ssh -i admin.key git@{IP} whoami` can give you information about the admin user | 18:24 |
persia | And after all that, "CRIT: Repository local-config/lorries does not exist" | 18:25 |
pedroalvarez | that's odd | 18:28 |
persia | Yes :) | 18:29 |
pedroalvarez | does the system have: /home/git/repos/{TROVE_ID}/local-config/lorries.git ? | 18:29 |
*** robtaylor [~robtaylor@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:30 | |
*** rdale_ [~quassel@123.Red-79-147-219.dynamicIP.rima-tde.net] has joined #baserock | 18:31 | |
* pedroalvarez has to head off | 18:32 | |
persia | Have a good night. | 18:33 |
*** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 18:34 | |
persia | That repo *does* exist. | 18:35 |
* persia does it locally | 18:35 | |
persia | It seems that the lorry proxy configuration requires a username and password, but not all proxies require them :( | 18:40 |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:55 | |
*** cosm [~Unknown@host-78-150-56-250.as13285.net] has quit [Ping timeout: 258 seconds] | 19:05 | |
*** elevenarms__ [~elevenarm@c-69-181-189-77.hsd1.ca.comcast.net] has joined #baserock | 19:17 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 19:19 | |
*** elevenarms_ [~elevenarm@c-69-181-189-77.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds] | 19:20 | |
*** robtaylor [~robtaylor@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:41 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:51 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:59 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 21:28 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 21:28 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:28 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:29 | |
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 256 seconds] | 21:36 | |
*** JPohlmann [~jannis@m65s13.vlinux.de] has joined #baserock | 21:38 | |
*** JPohlmann [~jannis@m65s13.vlinux.de] has quit [Changing host] | 21:38 | |
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock | 21:38 | |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:07 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!