using salt stack with riak
Hey all, We're implementing salt stack for configuration management, and I've been trying out how it works with riak, specifically remote command execution. Anyone out there in riak-land been successfully integrating it with salt? I've hit a couple of "arroo?" moments and am curious what others have experienced. -matt ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: using salt stack with riak
Nicely done Matt! Sure would love to see your states... I've got a fairly good one for riak-cs, would love to see some others. On Wed, Jan 22, 2014 at 2:14 PM, Matt Black wrote: > Hi Matt, > > We manage all our Riak infrastructure with a couple of Salt states and a > custom module I wrote which you can see here: > > https://github.com/saltstack/salt-contrib/blob/master/modules/riak.py > > There's another Riak module in Salt core, but last time I checked it had > less functionality. (I talked with them a while back about merging the two > modules - perhaps I should bring that up again). > > I can send our Salt states as well, if you're interested :) > > > On 23 January 2014 07:05, Matt Davis wrote: > >> Hey all, >> >> We're implementing salt stack for configuration management, and I've been >> trying out how it works with riak, specifically remote command execution. >> >> Anyone out there in riak-land been successfully integrating it with salt? >> >> I've hit a couple of "arroo?" moments and am curious what others have >> experienced. >> >> -matt >> >> >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> > ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: using salt stack with riak
Cool Matt, looks very similar to what I've got! We're also using pillar,
which helps a great deal when cross-referencing riak packages needed for
riak-cs.
On Thu, Jan 23, 2014 at 3:56 PM, Matt Black wrote:
> This state is meat of it, and should be pretty self-explanatory if you're
> already writing Salt states..
>
> riak-ulimit-pam:
> file.append:
> - name: /etc/pam.d/common-session
> - text: "session\trequired\tpam_limits.so"
>
> riak-ulimit-pam-noninteractive:
> file.append:
> - name: /etc/pam.d/common-session-noninteractive
> - text: "session\trequired\tpam_limits.so"
>
> riak-ulimit:
> file.append:
> - name: /etc/security/limits.conf
> - text:
> - "riak soft nofile 65536"
> - "riak hard nofile 65536"
> - require:
> - file: riak-ulimit-pam
>
> python-software-properties:
> pkg.installed
>
> basho-pkgrepo:
> pkgrepo.managed:
> - humanname: Basho PPA
> - name: deb http://apt.basho.com precise main
> - file: /etc/apt/sources.list.d/basho.list
> - key_url: http://apt.basho.com/gpg/basho.apt.key
> - require:
> - pkg: python-software-properties
>
> riak:
> pkg.installed:
> - version: 1.4.2-1
> - require:
> - pkgrepo: basho-pkgrepo
> riak.running:
> - require:
> - pkg: riak
> - file: /etc/riak/app.config
> - file: /etc/riak/vm.args
> - file: riak-ulimit
>
> /etc/riak/app.config:
> file.managed:
> - source: salt://riak/app.config
> - mode: 644
> - template: jinja
> - require:
> - pkg: riak
> - defaults:
> internal_ip: {{ salt['cmd.exec_code']('bash', 'hostname -I') }}
>
> /etc/riak/vm.args:
> file.managed:
> - source: salt://riak/vm.args
> - mode: 644
> - template: jinja
> - require:
> - pkg: riak
> - defaults:
> internal_ip: {{ salt['cmd.exec_code']('bash', 'hostname -I') }}
>
>
>
> On 24 January 2014 04:22, Matt Davis wrote:
>
>> Nicely done Matt! Sure would love to see your states... I've got a fairly
>> good one for riak-cs, would love to see some others.
>>
>>
>> On Wed, Jan 22, 2014 at 2:14 PM, Matt Black wrote:
>>
>>> Hi Matt,
>>>
>>> We manage all our Riak infrastructure with a couple of Salt states and a
>>> custom module I wrote which you can see here:
>>>
>>> https://github.com/saltstack/salt-contrib/blob/master/modules/riak.py
>>>
>>> There's another Riak module in Salt core, but last time I checked it had
>>> less functionality. (I talked with them a while back about merging the two
>>> modules - perhaps I should bring that up again).
>>>
>>> I can send our Salt states as well, if you're interested :)
>>>
>>>
>>> On 23 January 2014 07:05, Matt Davis wrote:
>>>
>>>> Hey all,
>>>>
>>>> We're implementing salt stack for configuration management, and I've
>>>> been trying out how it works with riak, specifically remote command
>>>> execution.
>>>>
>>>> Anyone out there in riak-land been successfully integrating it with
>>>> salt?
>>>>
>>>> I've hit a couple of "arroo?" moments and am curious what others have
>>>> experienced.
>>>>
>>>> -matt
>>>>
>>>>
>>>> ___
>>>> riak-users mailing list
>>>> riak-users@lists.basho.com
>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>>
>>>>
>>>
>>
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Core Claim and Property-Based Tests
I don't contribute to this list as much as I lurk in #riak (craque), but it's really great to see this kind of community support somewhere, especially at a large place that is heavily invested in riak itself. I have considered posting some of the operational lessons I've learned over the past five years on riak-based systems. If there will be an organized effort around these types of things, I'm here to help and would love to be involved as well. -matt On Wed, May 17, 2017 at 3:19 AM, wrote: > Apologies in advance if this doesn't quite submit correctly to the list. > > We [bet365] are very much interested in the continued development of Riak > in its current incarnation, with Core continuing to be underpinned by > distributed Erlang. We are very keen to help to build / shape / support the > community around the project. Internally, we have assembled a team to > continue the development of Riak, along a roadmap, and are also looking to > bring more expertise into the business to help support this. Whilst the > Lasp / Partisan project sounds really interesting, and something that could > probably be of interest to us in the future, our immediate focus is around > stabilising and securing the project in its current form. We’re looking to > take Riak forward by contributing to a renewed community effort. > > In summary, we're committed to continuing the development of Riak (we've > already assembled / growing a team to do so) and are happy to engage with, > and support, the community in order to move the project forward. > > Thanks > > Martin Cox > Software Developer > Hillside (Technology) Limited > e: martin@bet365.com > bet365.com > This email and any files transmitted with it are confidential and contain > information which may be privileged or confidential and are intended solely > to be for the use of the individual(s) or entity to which they are > addressed. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is strictly prohibited and may be illegal. If you have received > this email in error, please notify us by telephone or email immediately and > delete it from your system. Activity and use of our email system is > monitored to secure its effective operation and for other lawful business > purposes. Communications using this system will also be monitored and may > be recorded to secure effective operation and for other lawful business > purposes. Internet emails are not necessarily secure. We do not accept > responsibility for changes made to this message after it was sent. You are > advised to scan this message for viruses and we cannot accept liability for > any loss or damage which may be caused as a result of any computer virus. > > This email is sent by a bet365 group entity. The bet365 group includes the > following entities: Hillside (Shared Services) Limited (registration no. > 3958393), Hillside (Spain New Media) Plc (registration no. 07833226), > bet365 Group Limited (registration no. 4241161), Hillside (Technology) > Limited (registration no. 8273456), Hillside (Media Services) Limited > (registration no. 9171710), Hillside (Trader Services) Limited > (registration no. 9171598) each registered in England and Wales with a > registered office address at bet365 House, Media Way, Stoke-on-Trent, ST1 > 5SZ, United Kingdom; Hillside (Gibraltar) Limited (registration no. 97927), > Hillside (Sports) GP Limited (registration no. 111829) and Hillside > (Gaming) GP Limited (registered no. 111830) each registered in Gibraltar > with a registered office address at Unit 1.1, First Floor, Waterport Place, > 2 Europort Avenue, Gibraltar; Hillside (UK Sports) LP (registration no. > 117), Hillside (Sports) LP (registration no. 118), Hillside (International > Sports) LP (registration no. 119), Hillside (Gaming) LP (registration no. > 120) and Hillside (International Gaming) LP (registration no. 121) each > registered in Gibraltar with a principal place of business at Unit 1.1, > First Floor, Waterport Place, 2 Europort Avenue, Gibraltar; Hillside España > Leisure S.A (CIF no. A86340270) registered in Spain with a registered > office address at C/ Conde de Aranda nº20, 2º, 28001 Madrid, Spain; > Hillside (Australia New Media) Pty Limited (registration no. 148 920 665) > registered in Australia with a registered office address at Level 4, 90 > Arthur Street, North Sydney, NSW 2060, Australia; Hillside (New Media > Malta) Limited, (registration no c.66039) registered in Malta with a > registered office address at Office 1/2373, Level G, Quantum House, 75 > Abate Rigord Street, Ta’ Xbiex XBX 1120, Malta and Hillside (New Media > Cyprus) Limited, (registration no. HE 361612) registered in Cyprus with a > registered office address at Omrania Centre, 313, 28th October Avenue, 3105 > Limassol, Cyprus. Hillside (Shared Services) Limited, Hillside (Spain New > Media) Plc and Hillside (New Media Malta) Limited also have pla
