[Labs-l] Problems when setting up an instance of Wikidata

Leslie Carr lcarr at wikimedia.org
Tue Apr 17 17:23:53 UTC 2012


On Tue, Apr 17, 2012 at 10:14 AM, Daniel Kinzler <daniel at brightbyte.de> wrote:
> Hi Ryan
>
>> Agreed, this would be convenient. That said, we tend to use "role"
>> classes, that do most things via a single class.
>
> So, we'd need to make a role class for wikidata wikis? which includes all the
> webserver, mysql, etc cruft? This seems kind of redundant...

You can take the role class and include other classes in it (see most
any other server for examples).  That way you don't duplicate
packages. for example

class wikidata {
  include misc::puppet


>
>>> * MISSING: foll VM snapshots. But that's just "nice to have". Puppet templates
>>> would be much more useful.
>>>
>>
>> We'll eventually have this, but we always recommend using puppet over this.
>
> I actually agree - I care abotu the setup, not memory state.
>
> It would just be create to be able to replicate the puppet config for one
> instance to another.
>
>>> * BROKEN: We were unable to install a mysql server. Trying to apply db:core
>>> failed with an error. The error ocurrs when trying ot restart the ganglia
>>> monitoring daemon (gmon or whatever). It complains about a syntax error
>>> (unexpected token "}") in the config file.
>
> What about this? This seems to be a serious bug... Has anyone been hitting it?

The best thing about git is that anyone can submit a bugfix :)

>
>>> * BROKEN: Actually, installing mysql (db:core) initially failed with a different
>>> error: it's missing the directory /a. If that dir is needed, the puppet script
>>> should create it, no?
>
> So, is there any "plain" mysql class that we can use?
Add in generic::mysql::server using this page -
https://labsconsole.wikimedia.org/wiki/Special:NovaPuppetGroup


>
>>> * UNCLEAR: after changing the puppet config for an instance, when are the
>>> changes applied? We ended up running puppetd -tv manually from the shell...
>>> shouldn't the console just trigger that whenever the config is changes?
>>>

FYI it also runs once an hour.

>>
>> This would be ideal, but it isn't easy. Puppet runs can often fail, so
>> it's usually best to force a run. I guess when creating instances with
>> known working configuration it would be useful. I'll have to think
>> some about sane ways to implement this.
>
> How about a "run puppet now" button, that will start the puppet run and then
> take the user to the console output?
>
> Oh, btw - how about a "reload once per minute" option for the console output?
>
> Just a thought :)
>
>>> * MISSING/UNCLEAR: some puppet bundles are incompatible with each other. Trying
>>> to install all of apache2 and apache2:php5 and apache2:php5-mysql fails with an
>>> unhelpful error message about conflicting declarations. So, dependencies and
>>> conflicts between bundles should somehow be indicated (or at least there should
>>> be meaningful messages on the console).
>>>
>>> * UNCLEAR: which are the bundles needed to install a standard LAMP stack?
>>>
>>
>> We really need docs for our puppet repo. Honestly, though, our answer
>> for this right now is "it kind of depends on what you are trying".
>
> I'm trying to set up a common development playground for the wikidata team. for
> internal tests and demos. So, I need a minimum environment capable of running
> mediawiki.
>
>> Yep, this would be nice. You're supposed to get an email when the
>> instance is finished building itself, but this isn't working at this
>> moment.
>
> that would already help a lot, yea.
>
>>> We'd be very grateful for any input on the above issues. As it stands, we'll be
>>> using labs as a plain VM hoster, and install everything by hand. Which kind of
>>> sucks...
>>>
>>
>> Well, at its most basic level, that's what Labs is. The strength of
>> Labs is the ability to change things about it, and letting us know
>> your issues like this is definitely one way to help the community do
>> so. I hope our responses helped you some.
>
> Well, the git-via-puppet integration is a pretty cool idea, but the need to gro
> through review is a bit combersome.
>
> I'd like every labs project to have their own git repo for puppet and other
> config stuff. That would be very convenient, especially for things that are
> really not intended to ever be applied to wmf production boxes.
>
> thanks
> daniel
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l



-- 
Leslie Carr
Wikimedia Foundation
AS 14907, 43821
http://as14907.peeringdb.com/



More information about the Labs-l mailing list