Oyster at the NWE.pm Hackday (pt1)

. 4 comments.

Mark Keating has already blogged in detail about the NorthWestEngland.pm Hackday 2010 from a social & logistic point of view, and I’ll just agree here that it was indeed awesome in the true sense of the world!

Instead, I’d like to wrap up some detail about Oyster itself, the project that about a dozen of us (the majority of the physical attendees) worked on.

Goal for the day

Our rough goal was to be able to provision a simple webapp (a “Hello World”) onto one of the Cloud backends. We didn’t quite make this, but we did create many of the pieces required.

Project resources

  • wikipage linking to pages on tasks, roadmap, APIs etc.
  • an IRC chat channel. #oyster on irc.perl.org
  • no mailing list yet. For now, use the NWE.pm one if required…
  • a git repo p5sagit@git.shadowcat.co.uk:Oyster.git. Nopaste your ssh public key on #oyster to get push access.
  • I’m also pushing to github

Client

Me, Rob (el_bandido), and Mark (n0b0dy) worked on this. Our user story is that we’d be able to:

$ oyster new My-App        # creates a new Oyster/Catalyst project
# edit code
$ git commit
$ oyster provision test      # creates a server called "test"
$ git push oyster-test       # deploy to the server provisioned above

Because one of our goals was to reuse the good work in specifying Modern Perl development tools in Task::Kensho, we started off trying to use Dist::Zilla as the interface for the above.

Advantages of Dist::Zilla

  • plugin oriented: already has plugins to do things like
    • check dependencies
    • commit to git
    • scp tarballs
    • create new commands
  • Actively developed
  • Moosey

Disadvantages of Dist::Zilla

  • Being a complex, highly factored Moose project, it’s hard to find where functionality, or datastructure declaration is actually implemented
  • … and therefore correspondingly difficult to implement, say, a new command, or way of gathering config
  • … the documentation is excellent for users wanting to use Dzil for its current purpose. But less so for people like us wanting to abuse it to do slightly different things. (I suspect that we would now be ready to hit IRC #moose to get support and perhaps contribute back to the docs as we do so).
  • As Matt pointed out, most Catalyst projects are not using Dzil, but rather Module::Install. Using Dzil might be a little niche?
  • For provisioning servers, we really need a multi-level configuration. 
    {
   test => {
      username => ...
      password => ...
   },
   live => {
       ...
   }
}

    But it really seems that Dzil expectes an ini file for everything. We kludged this by having a separate oyster config file using Config::General.

We’re currently considering whether to persevere with Dist::Zilla, or move to something simpler like App::Cmd, stealing modules, ideas, and code from Dzil as appropriate ;-)

Coming up in part 2

I’ll summarize the work on

  • the Backend cloud servers
  • the deployment phase
  • documentation, testing, and marketing