| Mode #baserock +o Kinnison by asimov.freenode.net | 00:25 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:25 | |
| *** wikicat [~wikicat@ec2-54-77-166-165.eu-west-1.compute.amazonaws.com] has joined #baserock | 00:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 03:38 | |
| *** petefotheringham [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 04:41 | |
| *** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:09 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 06:20 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 06:21 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 06:21 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:21 | |
| petefotheringham is now known as petefoth | 06:27 | |
| pedroalvarez | urgh. the irc logs are all in one page.. I knew this was going to happen. | 07:06 |
|---|---|---|
| pedroalvarez | good news! cross-bootstraping a system with fake-bash in the stage2 works! | 07:13 |
| pedroalvarez | If anyone is interested, my WIP branch is baserock/pedroalvarez/glibc on definitions.git | 07:19 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:38 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:47 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 07:58 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:58 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 08:04 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:04 | |
| *** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:12 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:15 | |
| Kinnison | pedroalvarez: cool! | 08:22 |
| persia | pedroalvarez: http://ci.openstack.org/meetbot.html is the config I was looking at to do IRC logging the complicated way, if you want to avoid building something from scratch. | 08:24 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:26 | |
| Mode #baserock +v ssam2 by ChanServ | 08:26 | |
| * pedroalvarez reads that as meatball | 08:30 | |
| * Kinnison thinks pedroalvarez needs lunch already | 08:31 | |
| pedroalvarez | hahah I need breakfast first | 08:32 |
| rjek | Bacon butty time? | 08:32 |
| *** jjardon_ [~jjardon@demo.convos.by] has joined #baserock | 08:37 | |
| petefoth | the 'Guide to running Baserock in a Virtual Machine' currently says to use ssh-add before ssh-ing to the VM when using VB, biut doesn't mention it for KVM or QEMU. Do you need to run ssh-add in thiese two setups? | 08:45 |
| persia | You don't need to do it for *any* virtualisation, but you may for any. | 08:46 |
| persia | It gives the guest access to the host's keys, which may or may not be a good idea, depending on the access granted to the host keys, and the access wanted on the guest. | 08:47 |
| petefoth | persia: thanks. So do you need to run it before you use `ssh -A ...`? | 08:48 |
| persia | Right. If you aren't using ssh -A, it doesn't help. | 08:49 |
| persia | Unless you're ssh'ing into the baserock instance, and need a key to do so... | 08:49 |
| petefoth | persia: great, thanks | 08:50 |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:57 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:03 | |
| *** zarazaimeche [~zarazaime@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:12 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:12 | |
| zarazaimeche is now known as Zara | 09:18 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 09:24 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:25 | |
| wikicat | Wiki change: Use the 'meta-title' for the vm-setup guide http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=3f6e2d0 | 09:33 |
| wikicat | Wiki change: Rationalise 'Quick start' and 'Create a Development VM' pages. Remove duplication. http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=4915923 | 09:33 |
| wikicat | Wiki change: Use consistent formatting in KVM section http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=59ac502 | 09:33 |
| wikicat | Wiki change: Previous commit didn't work, so use the proper title http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=d151633 | 09:35 |
| ssam2 | SotK: I'm not quite sure what's best w.r.t. OpenStack config in your patch series | 09:36 |
| ssam2 | I guess for now, setting up a Mason in OpenStack is not something we expect the whole world to be doing | 09:36 |
| ssam2 | so no point spending lots of time on this. Just do whatever is easiest, but make it clear somehow that the user can download the .rc file from the Horizon web interface | 09:37 |
| ssam2 | the fact that they'll have to then edit it to add quoting suitable for Ansible is a bit sucky, though ... | 09:37 |
| persia | I'd rather that be the default actually: elastic instances. We can use a baserock-based stack for folks that don't have one in place. | 09:37 |
| ssam2 | persia: ok, I'm just saying this in the context of trying to avoid blocking SotK's current patch series for too long :) | 09:38 |
| persia | Not blocking is better than honoring my preferences :) | 09:38 |
| ssam2 | if you have any ideas on how to make it easy for the user to inject their openstack credentials into Mason at deployment time, they might be useful, though | 09:39 |
| wikicat | Wiki change: More typos and formatting http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=44865d9 | 09:39 |
| wikicat | Wiki change: Typos and formatting http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=fe6869c | 09:39 |
| ssam2 | although this whole approach is still provisional because it involves them storing their password in the Mason, right ? | 09:39 |
| SotK | yep | 09:39 |
| ssam2 | right. So just make that fact clear in the openstack template and I'm happy :) | 09:39 |
| SotK | ok then, thanks :) | 09:40 |
| persia | I'd suggest that when Mason is all-OpenStack, Mason ought get credentials from Keystone | 09:40 |
| ssam2 | for the user who 'owns' it? or would it have to have its own credentials? | 09:42 |
| ssam2 | I note that you seem to be able to pass a token for OpenStack authentication rather than providing your password each time, but I'm not clear on exactly how that works | 09:42 |
| ssam2 | i'm thinking of rearranging the systems we have. basically I want to rename 'distbuild' to 'build', and add lots of stuff (Ruby, Node, more Python packages and eventually the Baserock Import tool) to devel | 09:49 |
| ssam2 | and then change clusters/release.morph so that we release the build-system rather than the now-larger devel-system | 09:49 |
| ssam2 | anyone strongly for or against this idea, before I spend the time doing it ? | 09:49 |
| straycat | distbuild to build? | 09:50 |
| ssam2 | that's what I said, do you have a comment on that ? | 09:50 |
| straycat | why? | 09:50 |
| ssam2 | because it'll be a generic "system that can build other systems" | 09:51 |
| ssam2 | that can be used either for local builds, or distributed builds | 09:51 |
| straycat | isn't that what our devel system is? | 09:51 |
| wikicat | Wiki change: Changes after 'final' proof-read. Ready for isnpection by #baserock http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=af3d055 | 09:51 |
| ssam2 | it is right now, but I want to add other stuff to the devel system | 09:51 |
| ssam2 | making it much larger | 09:51 |
| ssam2 | that way, there will be somewhere to integrate the import tool where it'll have all of the dependencies it needs available to work 'out of the box' | 09:52 |
| ssam2 | do you have other ideas on which system the import tool could live in ? | 09:52 |
| wikicat | Wiki change: formatting http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=ea38b82 | 09:53 |
| wikicat | Wiki change: Move the ToC http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=ac61dcc | 09:53 |
| wikicat | Wiki change: fix the ToC http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=d14a9aa | 09:53 |
| petefoth | I have made some changes to the 'Quick start' page and the the 'Create a Development VM' guide. I would be grateful if anyone has time to check that I haven't introduced any factual errors. The changes are to remove duplication, and pout everything in a more coherent order. | 09:54 |
| petefoth | Links http://wiki.baserock.org/quick-start/ and http://wiki.baserock.org/guides/vm-setup/ | 09:54 |
| straycat | I don't have an opinion on that | 09:55 |
| wikicat | Wiki change: formatting http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=613150b | 09:55 |
| Zara | Ooh, I approve of 'You added a second drive to the VM when we created it.'; the first time I used baserock I was unsure if I'd done that or not. | 09:57 |
| petefoth | Zara: you *might* have done :)_ | 09:58 |
| * petefoth apologises for al the Wiki change posts: editing locally rather than in-place means I don't spot formatting errors | 10:00 | |
| straycat | .quit | 10:01 |
| *** wikicat [~wikicat@ec2-54-77-166-165.eu-west-1.compute.amazonaws.com] has quit [Quit: straycat] | 10:01 | |
| pedroalvarez | is gone! | 10:01 |
| straycat | It would be cool if branchable had all the private branches online | 10:02 |
| straycat | then you could get feedback before you merge | 10:02 |
| Zara | petefoth: heh, well somebody who was familiar with setting up VMs wouldn't need that reassurance because they'd know how to check, but I didn't know if it had done it or not. | 10:02 |
| * pedroalvarez has a public kanban board to track the things that he is doing in baserock https://trello.com/b/rShl98Nc/baserock-things | 10:18 | |
| Kinnison | pedroalvarez: neat | 10:19 |
| richard_maw | pedroalvarez: can you add richardmaw1 to it, so I can track my stuff on there? | 10:29 |
| pedroalvarez | richard_maw: sure :) | 10:31 |
| pedroalvarez | this is a nice thing to have :) | 10:33 |
| pedroalvarez | richard_maw: you are welcome to do whatever you want | 10:33 |
| pedroalvarez | e.g. I'm not currently doing all what I have in the "Doing" lane, so maybe adding another lane makes sense | 10:37 |
| persia | ssam2: Sorry: was distracted, whether Mason uses owner credentials or defined role credentials would be deployment decision. Oranisations that prefer personal accountability or have limited access to provider clouds would probably use owner credentials, and organisations that control the cloud would probably use role credentials. | 10:38 |
| persia | I have limited understanding of Keystone, but I think that one can pass a token and the keystone URI to any OpenStack service, and the service will communicate with Keystone to validate that the token is both current and authorised for the service in question. | 10:39 |
| ssam2 | persia: makes sense. Mason is designed for both 'personal try-server' use and 'project-wide continuous testing' | 10:39 |
| persia | So only the interaction with Keystone needs a password, which is only used to initialise the token. | 10:39 |
| ssam2 | right, so as long as the tokens don't expire very often we can have Mason prompt the user for a password on first boot, and then store only a token | 10:40 |
| persia | Hmm. So whether to have Mason OpenStack-by-default is rally a matter of whether we can expect most folk to have access to an OpenStack cloud. | 10:40 |
| persia | This decision would be easier with `morph deploy openstack-cloud` :) | 10:40 |
| Kinnison | I believe franred is working towards having openstack on baserock at which point I believe we can | 10:40 |
| persia | Kinnison: Do we need to support folk on disconnected laptops that can't do nested virtualisation? | 10:41 |
| persia | ssam2: I think Keystone token expiration rules are configurable by installation | 10:42 |
| Kinnison | persia: I don't know that laptops lacking nested virt will be powerful enough to runa full mason env anyway will they? | 10:42 |
| persia | There were some dual-socket Nehelem laptops sold, but yeah, the people who bought those probably already upgraded. | 10:43 |
| persia | Perhaps more interesting is the case for other architectures, where nested virtualisation support is even newer. | 10:44 |
| persia | I don't believe it to be supported by Cortex-A9, but that is still a popular core. I'd be happy to be wrong, if someone has better data. | 10:44 |
| straycat | self.settings.boolean( | 10:45 |
| straycat | ['no-act', 'dry-run', 'pretend', 'n'] | 10:45 |
| straycat | Why do you need that many flags for one setting? | 10:46 |
| Kinnison | persia: I think you need A15 before virtualisation is really sensible full-stop, no? | 10:46 |
| Kinnison | straycat: because they're all common aliases | 10:46 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:46 | |
| Kinnison | principle of least surprise suggests that where there are common terms for things, we support them as aliases | 10:46 |
| rjek | You can virtualise one guest with an ugly hack on any ARM with TrustZone. A15 has TrustZone++ | 10:46 |
| straycat | Kinnison, Okay | 10:47 |
| persia | Kinnison: That matches my understanding, which makes me think an ARM OpenStack is harder to arrange than an ARM deployment target. | 10:47 |
| Kinnison | persia: To some extent -- things like the jetson TK1 are making it more and more likely we can do ARM OpenStack in the near future | 10:48 |
| Kinnison | persia: and Once aarch64 gets going properly, it ought to solve an awful lot more | 10:48 |
| persia | bit width shouldn't make much diffrence, but yeah, I suppose it's easy enough to get at least A15 if one wants to do validation. | 10:50 |
| rjek | ARM64 isn't just about bitwidth, it's a completely different design with modern features | 10:50 |
| persia | Yes, but does it have significantly different capabilities in the narrow scope of nested virutualisation support from A15 or higher? | 10:51 |
| rjek | I believe its virtualisation extensions are a bit better, yes. I think the virtual interrupt controller is nestable without too much dancing about | 10:52 |
| persia | Ah, then yes. | 10:53 |
| rjek | bjdooks probably knows for sure, but he's not here :) | 10:54 |
| petefoth | so, remind my why Baserock shouldn't use Trello as it's public facing task tracker. I know it's not Baserock, and it wan't invented here, but it seems to do several things that would be useful for the project. | 11:02 |
| ssam2 | petefoth: I don't think anyone's ever said it would be bad to use Trello as the public facing task tracker, or suggested doing it before | 11:04 |
| ssam2 | if pedro and richard_maw like using it then perhaps it's a good choice | 11:04 |
| persia | 1) It's hosted somewhere, so we can't trust it will remain there, 2) Kanbans don't tend to handle elastic resource scaling well, and have lots of overhead when it comes to defining new and interesting tasks | 11:04 |
| persia | Mind you, in the absence of anything else, it is perhaps better than nothing for folk who like to do that sort of thing. | 11:05 |
| persia | But I don't think it's the place I should go put whatever ideas I have that I want someone to implement | 11:05 |
| persia | (or random problems I discover) | 11:05 |
| petefoth | s/folk/projects/ ? | 11:05 |
| persia | And if we have somewhere that does that, it makes more sense to use that also as a task tracker. | 11:05 |
| jmacs | Isn't our current kanban "hosted somewhere"? | 11:05 |
| persia | petefoth: No, folk. Projects do not have desires. | 11:06 |
| persia | jmacs: We don't have a kanban currently. | 11:06 |
| jmacs | Do we have a current task tracker? | 11:06 |
| * persia uses "folk" to mean both corporeal and statutory entites that have achieved sufficient competance to express themselves on the internet | 11:06 | |
| persia | jmacs: No, sadly, which is why I'm not arguing against using Trello very strongly :) | 11:07 |
| * petefoth wonders whether 'jmacs' is the Java implementation of em.... Oh never mind! | 11:07 | |
| pedroalvarez | I was only using trello for myself, because I don't have a good memory and I wanted to track my work | 11:08 |
| persia | Which is a good thing :) | 11:09 |
| pedroalvarez | after that I thought that maybe other people is interested in what I'm doing, so I decided to make the board public | 11:09 |
| pedroalvarez | and richard decided to join it :) | 11:09 |
| pedroalvarez | I agree we should move to something else, but for now is more than enough for me | 11:10 |
| * petefoth joined it to and will use it for tracking work on w.b.o | 11:10 | |
| petefoth | s/to/too/ | 11:10 |
| persia | I think anyone who finds it useful should join, and that we still need a proper issue tracker, and should use that for task tracking once it works. | 11:11 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 11:11 | |
| petefoth | pedroalvarez: I think I've sibscribed to the Baserock things board but how do I 'join' as a member? | 11:34 |
| richard_maw | petefoth: you get invited | 11:36 |
| petefoth | richard_maw: pedroalvarez: please sirs! May I be invited? | 11:36 |
| richard_maw | petefoth: which petefoth do you want to be invited | 11:36 |
| richard_maw | petefotheringham or petefotheringham1? | 11:36 |
| petefoth | richard_maw: ah! let me go away and think about that> I'll be back shortly | 11:37 |
| petefoth | richard_maw: petefotheringham please | 11:41 |
| pedroalvarez | petefoth: done! | 11:42 |
| richard_maw | pedroalvarez: what was your final review for "[PATCH 0/7] Lorry Controller: remove old job information automatically"? | 11:45 |
| pedroalvarez | I'm testing it. If the service and the timer work I'll +1 it and merge it | 11:46 |
| richard_maw | ah, cool, I was just worried it was forgotten | 11:47 |
| pedroalvarez | I intend to finish that today | 11:47 |
| petefoth | Hmm - so I had three Trello accounts. Now I'm down to a more manageable two :) | 11:50 |
| pedroalvarez | petefoth: why not only one :) | 11:51 |
| petefoth | pedroalvarez: because there's 'work' and there's 'not work'. I try to keep them separate. I'm old-fasioned like that! :) | 11:52 |
| pedroalvarez | petefoth: i understand what you mean. | 11:55 |
| pedroalvarez | for example, now in my android widget I have all of them mixed | 11:55 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 12:05 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [] | 12:05 | |
| *** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:53 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:26 | |
| Krin | if i smile and ask nicely, could someone who knows what they are doing add the following to the lorry system? http://pastebin.com/uEK71gKf && http://pastebin.com/0t9h90Z9 | 13:26 |
| richard_maw | Krin: is cppunit a unit testing framework? | 13:27 |
| * Kinnison has looked, it's like junit | 13:27 | |
| * Kinnison shudders | 13:27 | |
| * Kinnison thinks the lorries look good | 13:27 | |
| richard_maw | you need that at build-time? | 13:27 |
| Kinnison | richard_maw: looks like some of zookeeper's autotoolery needs it, it has automake macros in it | 13:27 |
| richard_maw | eww | 13:28 |
| Krin | i know it's icky and covered in slimey things but... | 13:28 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 13:29 | |
| Kinnison | Has someone got a local-config/lorries repo to hand and can add Krin's lorries? | 13:50 |
| pedroalvarez | yup | 13:50 |
| Krin | yay ^.^ | 13:50 |
| pedroalvarez | do we agree to add them? | 13:51 |
| * Kinnison gives them a +2 | 13:51 | |
| Kinnison | we want zookeeper and it needs cppunit | 13:51 |
| * pedroalvarez adds them | 13:51 | |
| Kinnison | thanks pedroalvarez | 13:51 |
| pedroalvarez | looks like we decided to configure only 2 minions on the latest g.b.o. upgrade | 13:57 |
| pedroalvarez | there are a lot of things waiting in the LC queue: http://git.baserock.org/lc-status.html | 13:57 |
| richard_maw | ssam2: I've updated my parallel yarn branch to fix the status reporting | 13:57 |
| pedroalvarez | this wasn't usual before | 13:57 |
| Kinnison | pedroalvarez: yeah 2 because 4 kept running the system out of RAM on some of the larger lorry jobs | 13:58 |
| Kinnison | Looks like zookeeper has started \o/ | 13:59 |
| persia | Can mariadb be lorried with only two minions? | 13:59 |
| Krin | zookeeper has started what Kinnison? | 13:59 |
| Kinnison | Krin: lorrying | 13:59 |
| Kinnison | persia: mariadb can only be lorried if we use tarball import | 14:00 |
| persia | :( | 14:00 |
| Kinnison | persia: the from-vcs import needs nearly 120G of working area | 14:00 |
| Kinnison | persia: ancient project which followed the GNU changelog standard | 14:00 |
| pedroalvarez | aren't we lorrying mariadb from git? | 14:00 |
| Kinnison | Oh if we are then it should be okay | 14:00 |
| Kinnison | if someone else is taking the conversion hit | 14:00 |
| pedroalvarez | http://git.baserock.org/cgi-bin/cgit.cgi/delta/mariadb-git.git/ | 14:01 |
| pedroalvarez | they have moved to github :) https://blog.mariadb.org/mariadb-moves-development-to-github/ | 14:05 |
| franred | anyone is against to change the repositories inside of the .gitsubmodules by the trove repos in configuration time? like: http://fpaste.org/144168/86719141/ | 14:06 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:06 | |
| pedroalvarez | hm... | 14:07 |
| franred | this will allow us to be able to update the sha and unpetrify-ref and not having to create and then actualizing a branch | 14:07 |
| pedroalvarez | franred: I think that is not enough | 14:07 |
| franred | pedroalvarez, why not? | 14:07 |
| pedroalvarez | I think that morph clones the .gitmodules *before* running any command | 14:08 |
| franred | pedroalvarez, you are right | 14:08 |
| pedroalvarez | would be great if you can specify in a startum that you want to clone some repositories inside the chunk source before running any command | 14:09 |
| franred | clone trigger the gitsubmodules | 14:09 |
| pedroalvarez | not sure if it's the right thing to do for git submodules though | 14:10 |
| franred | yep, but it is not enough | 14:10 |
| franred | we should trigger this at lorry time, though | 14:10 |
| franred | so if lorry-controller lorry a repo which contains submodules, create the lorry files for them? | 14:11 |
| richard_maw | franred: difficult, since technically you would need to scan _every_ commit of _every_ branch for submodules | 14:12 |
| richard_maw | plus, to actually use them sensibly, you'd have to have lorry create duplicate branches of everything, where it's used filter branch to change what the submodules point to | 14:12 |
| richard_maw | _this_ is why in the trello I've got "Allow chunks with multiple source repositories", so we could stop parsing the .gitmodules, and have the morphology say which submodules are needed | 14:13 |
| franred | ummm, you are right | 14:15 |
| pedroalvarez | richard_maw: should we enable the "voting" power-up so the people can vote for the new features? | 14:16 |
| richard_maw | in the trello? | 14:18 |
| pedroalvarez | yup :) | 14:18 |
| richard_maw | I guess, provided people understand that it's not binding. | 14:19 |
| richard_maw | It would be nice to know whether people would prefer I start adding in-line chunk morphologies before I try to unify distbuild with local build | 14:20 |
| pedroalvarez | see, a voting system makes soms sense | 14:20 |
| straycat | richard_maw, I don't see why it matters | 14:33 |
| straycat | So I don't have a preference | 14:35 |
| pedroalvarez | would an storyboard instance replace the trello board that we have created? | 14:41 |
| ssam2 | it'd be handy if we all used storyboard | 14:43 |
| ssam2 | I wouldn't really try and enforce anything, personally | 14:43 |
| ssam2 | Anything is better than us each having private TODO files (the one true way of managing tasks) | 14:43 |
| pedroalvarez | I'm just wondering if it would make our lifes easier in some way | 14:45 |
| petefoth | StoryBoard would be greate but, as we were discussing recently it needs to be hosted somewhere, and we're not sure that the chosen hostin location is ready for us.... | 14:47 |
| petefoth | StoryBoard is also a tool that the OpenStack teams are *moving* to as a replace,ment for some or all of the things that they yave used launchpad for in the past. Though I think they arte still using Jira for bug tracking (I may be wrong about this) | 14:49 |
| ssam2 | is StoryBoard good for tracking open-ended "this is a usecase we want to provide ongoing support for" tasks ? Is it only for stuff which has a defined 'now this is finished' point ? | 14:55 |
| ssam2 | i've been wondering where we should document the use cases we collect as part of our 'community' discussions | 14:56 |
| persia | OpenStack is using Malone for bug tracking (part of the Launchpad suite). As I understand it, final plans for transition are scheduled for the week past next. | 15:01 |
| petefoth | ssam2: I think the answer, unsurprisingly, is 'it depends.' I see no reason why you shouldn't use it to have long-runnign stories, which get active tasks against them every now and then. The story is the reference point for the requirements, and linking related tasks to it can ensure that the tasks don't get detached from the original story | 15:01 |
| petefoth | persia: thanks. It's a wjhile since I looked | 15:02 |
| ssam2 | petefoth: ok. do the requirements go in the description of the story? | 15:03 |
| ssam2 | or is there a hidden 'requirements' section that I'm yet to discover ? :) | 15:03 |
| persia | ssam2: Yes, Storyboard is specifically designed to go from "here's a thing that folk want to do" or "here's a thing that doesn't work" to code enabling those features/fixing those bugs/addressing those issues in a tracked way, integrated with version control, and allowing discussion on a per-item basis while retaining collaborative editing of the formal description of the problem. | 15:03 |
| ssam2 | cool. that's something can't really be done with Trello (or any Kanban) | 15:04 |
| persia | Right. The other thing kanbans don't handle well is random folk randomly adding things to do, which Storyboard handles well. | 15:05 |
| persia | On the other hand, StoryBoard doesn't currently provide a good dashboard. There's been some interesting talk in #storyboard about adding a kanban-like front-end, but I haven't seen much code to back that, nor do I know of anyone planning to go to Paris to describe their work in the area. | 15:05 |
| petefoth | I don't think there is a hissed section. When looked at the OpenStack stuff, they actually used 'specs' (text files in their own repo, subjetc to review using gerrit) for specifying requirments which then became stories (or things in Lanchpad - as I say it's a while since I looked). I think we could do that in baserock - have the spec under git, refer to the spec in related stories in StoryBoard, then crtetae tasks for the stopries. | 15:06 |
| petefoth | I would *really* like to have requirments under change control, and git adn gerrit can give us that, quite chealp. | 15:07 |
| petefoth | I will try to dig out a ling to thew OpenStack specs repo | 15:07 |
| persia | The specs repos are a repalcement for the Launchpad Blueprints functionality. | 15:08 |
| persia | I don't really like that format of specifications, much preferring narratives backed by behavioural scenario descriptions (e.g. yarn). My thought is that in Storyboard when creating a new story, it would include tasks to define a formal narrative somewhere, along with one or more scenarios for validation, as well as any code changes. | 15:09 |
| petefoth | https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs desscribes how they use (or have used) SPec and http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno-template.rst gives an example template | 15:17 |
| *** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 15:19 | |
| petefoth | persia: Hown would you suggest that changes to requirments / narratives in StoryBoard be controlled? I believe that they should be subject to the same level of review (e.g. using gerrit or some other tool) as code (and any other valuable document) | 15:20 |
| persia | Right. I think we could do better, but that model evolved from a wild experiment in Australia, where folk wrote down things they wanted to do on wiki pages, and a board convened to decide which to fund over a couple days. | 15:20 |
| persia | petefoth: I think discussion and high-level description on Storyboard should be uncontrolled, and anything that forms a basis of validation (like the narratives linking scenarios) be controlled in git. | 15:21 |
| persia | I'm not sure whether it gets the same level of review as code, more review, or less review. I've seen projects that did it all three ways, and each has pain points. | 15:21 |
| persia | WIth more review, the core team doing that review can more effectively drive direction, but it limits random feature adds by random folk. | 15:22 |
| * petefoth probably doesn't disagree with much / any of that but | 15:22 | |
| * petefoth has to catch a train, but will try to check back in here later | 15:22 | |
| petefoth | Otherwise, tomorrow | 15:22 |
| petefoth | ssam2: are you sorry you asked yet? ;) | 15:23 |
| persia | With less review, the validation code tends to cover a much richer set of usecases, but this limits development (because of contraints on what legacy behaviour must be supported), and tends to create an us vs. them state between developers and those contributing to validation. | 15:23 |
| persia | With the same level of review, everyone seems unhappy because either 1) there is a shared identity between drivers, developers, and user support, or 2) one of these three groups is superior, and the others are being held back because they are slow. | 15:24 |
| persia | petefoth: Have a good commute :) | 15:24 |
| richard_maw | hm, there's currently no tests for the system-integration commands | 15:27 |
| richard_maw | pedroalvarez: any suggestions? | 15:27 |
| richard_maw | I only noticed because I stumbled on the code and discovered it also suffers from the mount namespace problem which causes it to be unable to be run in parallel | 15:28 |
| pedroalvarez | richard_maw: I looked at it when I implemented them, but they needed run_parts in the system it didn't have even shell! | 15:28 |
| pedroalvarez | (test systems) | 15:29 |
| richard_maw | hm, sounds like we either need to extend the test shell to work as run-parts, or drop the use of run-parts entirely | 15:34 |
| richard_maw | our use of it ought to be simple enough to do by executing the files in the directory in order | 15:34 |
| *** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:14 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 16:25 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 16:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:25 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:31 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 16:32 | |
| * straycat is struck with fear after running offlineimap | 16:46 | |
| pedroalvarez | richard_maw: I see some suggestions from you in the lorry-controller patch | 16:49 |
| pedroalvarez | do you want to do that merge and I do the trove-setup one? | 16:49 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:54 | |
| richard_maw | pedroalvarez: I've already stopped doing e-mail today, but I could look at it tomorrow. | 17:12 |
| richard_maw | but IIRC my suggestions were optional | 17:13 |
| richard_maw | the only one left worth doing is the contextlib.closing(urllib.urlopen(url)) | 17:13 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:14 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 17:28 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:49 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:49 | |
| *** jjardon_60 [~jjardon@ec2-54-171-110-224.eu-west-1.compute.amazonaws.com] has joined #baserock | 18:12 | |
| *** jjardon_ [~jjardon@demo.convos.by] has quit [Quit: jjardon_] | 18:17 | |
| *** jjardon_60 [~jjardon@ec2-54-171-110-224.eu-west-1.compute.amazonaws.com] has quit [Quit: Bye!] | 18:19 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:22 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 19:05 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 256 seconds] | 21:36 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!