Dear Alessandra,
On 24 June 2013 10:04, Alessandra Forti <[log in to unmask]> wrote:
> Dear Luke,
>
>
>> However, I had the impression from HEPSYSMAN they we are going for the
>> development of general modules that will benefit all of the sites.
>
>
>
> "they" is "we".
Sorry, I meant "that".
>
> The decision to use www.sysadmin.hep.ac.uk was taken at the previous
> hepsysman in Lancaster. Admittedly few months have passed and few more
> people have "dirtied" their hands with puppet so we might have passed the
> stage of sharing ideas only ideas and the decision might not make sense
> anymore. But I haven't had that impression at the last hepsysman. I've seen
> two completely different presentations and no direction taken. I'm more than
> happy to drop it here if people are really going to produce general modules
> and put them into git. What I'd rather not want to see is the usage of two
> different places or nothing shared at all because it's not polished enough -
> as it happened in the past.
I understand. Confusion and fragmentation are the last things we need.
What is the general mood out there? Are people happy with the sharing
approach or should we put some efforts towards more general Puppet
modules which can be used at any site?
I am happy to refactor some of the modules in SVN into proper Puppet
modules if everyone is OK with it. We are setting up a new cluster
here at Bristol and I want everything to be done via Puppet. But if we
want to match Quator, which was one of the ideas at the last
HEPSYSMAN, then we will need more people doing it.
What do you think?
Cheers,
Luke
>
> cheers
> alessandra
>
>
>
> On 24/06/2013 09:53, L Kreczko wrote:
>>
>> Dear Alessandra,
>>
>> Yes, for sharing snapshots that is a good way to go.
>> However, I had the impression from HEPSYSMAN they we are going for the
>> development of general modules that will benefit all of the sites.
>> Otherwise we will be doing a lot of copy & paste + own modifications,
>> hence not reducing the overall effort.
>>
>> My aim is to create such modules and everyone is welcome to contribute at:
>> https://github.com/HEP-Puppet
>>
>> The goal is to create fully functional (i.e. installable via 'puppet
>> module install <modulename>'), testable and site-independent modules
>> as it is partially achieved for
>> https://github.com/HEP-Puppet/puppet-cvmfs.
>> I you want a full example of such a module, I think this one is quite
>> good:
>> https://github.com/puppetlabs/puppetlabs-mysql
>>
>> Also, I assume the SVN repository you pointed me to is public. You
>> probably don't want the certificates files to be there:
>>
>> http://www.sysadmin.hep.ac.uk/svn/fabric-management/puppet/durham/modules/service_node/files/
>>
>> Cheers,
>> Luke
>>
>> On 23 June 2013 22:48, Alessandra Forti <[log in to unmask]> wrote:
>>>
>>> Dear Luke,
>>>
>>> I'm not sure how many people will put that much effort on discussion
>>> boards
>>> and to review workflows but I take you point.
>>> The choice of sysadmin.hep.ac.uk was to share code snapshots to get ideas
>>> from each other without too much commitment to
>>> produce something that would work out of the box. Of course if this is
>>> what
>>> you are aiming at git is a better tool.
>>>
>>> cheers
>>> alessandra
>>>
>>>
>>> On 23/06/2013 22:34, L Kreczko wrote:
>>>>
>>>> Dear Alessandra,
>>>>
>>>> Thank you for pointing me to the repository, I did not know about it.
>>>> However, I noticed it is SVN (and a single repository). For a normal
>>>> use case this should be sufficient, but for the distributed nature of
>>>> this project, I would recommend git. In addition github provides easy
>>>> ways for code reviews (pull requests).
>>>>
>>>> Also, having one repository per module makes it very easy to follow
>>>> the changes (otherwise a change to a module in a big repository will
>>>> clutter the history). Another benefit of this is module testing: when
>>>> a module is correctly configured (Modulefile, metadata.json, etc).
>>>> This can even be automated using travis.org (very useful for
>>>> production grade modules!).
>>>>
>>>> To summarise my suggestions:
>>>> - git/mercurial is more suitable for distributed development than
>>>> SVN/CVS
>>>> - Github provides a very good web interface for discussion, code
>>>> review, distributed workflow, etc.
>>>> - one repository per module so the history is not cluttered (makes it
>>>> also easy to assign issues)
>>>>
>>>> Cheers,
>>>> Luke
>>>>
>>>>
>>>> On 23 June 2013 20:28, Alessandra Forti <[log in to unmask]>
>>>> wrote:
>>>>>
>>>>> Dear Luke,
>>>>>
>>>>> we decided quite some time ago to put things on the
>>>>> www.sysman.hep.ac.uk
>>>>> repository.
>>>>>
>>>>> http://www.sysadmin.hep.ac.uk/svn/fabric-management/puppet/
>>>>>
>>>>> Birmingham and Durham already started to post there. It's not
>>>>> compulsory
>>>>> but
>>>>> certainly less dispersive if we all use the same place.
>>>>>
>>>>> cheers
>>>>> alessandra
>>>>>
>>>>>
>>>>> On 23/06/2013 20:07, L Kreczko wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> Just to offer a common puppet module incubation area on github:
>>>>>> https://github.com/HEP-Puppet
>>>>>> Modules should benefit from being developed in the open (if suitable)
>>>>>> as
>>>>>> prompt feedback is possible.
>>>>>>
>>>>>> The first of my projects which might be useful to a wider (HEP)
>>>>>> audience
>>>>>> is
>>>>>> https://github.com/HEP-Puppet/puppet-apelpublisher
>>>>>> The module focuses on the installation and configuration of an Apel
>>>>>> EMI-3
>>>>>> publisher for SL6. Feedback (and help) is very welcome.
>>>>>> I am currently developing in the group area as it was my private area
>>>>>> but
>>>>>> hope to change that once more members join the group. Then I would
>>>>>> switch to
>>>>>> forking + pull requests.
>>>>>>
>>>>>> My Bristol T2/data intensive cluster config is slowly taking shape
>>>>>> here:
>>>>>> https://github.com/uobdic/dice_T2_puppet_config
>>>>>>
>>>>>> For data input (monitoring/ role definition) I am using Foreman, which
>>>>>> works in combination with hiera.
>>>>>>
>>>>>> Cheers,
>>>>>> Luke
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Facts aren't facts if they come from the wrong people. (Paul Krugman)
>>>>>
>>>>
>>>
>>> --
>>> Facts aren't facts if they come from the wrong people. (Paul Krugman)
>>>
>>
>>
>> --
>> ******************************************************
>> Lukasz Kreczko +44 (0)117 928 8724
>> CMS Group
>> School of Physics
>> University of Bristol
>> ******************************************************
>
>
>
> --
> Facts aren't facts if they come from the wrong people. (Paul Krugman)
>
--
******************************************************
Lukasz Kreczko +44 (0)117 928 8724
CMS Group
School of Physics
University of Bristol
******************************************************
|