Re: ANN: Riak 2.9.0 Urgent Patches Pending

[DeadZen]

We all appreciate it, and erring on the side of caution.  Thank you.

On Thu, Aug 22, 2019 at 12:22 PM Martin Sumner 
wrote:

> Follow-up on this announcement.  After further work today, it looks like
> the initial diagnosis of the Issue 1707 was incorrect, and that the defect
> does not obviously present a significant risk of data loss.  Work will
> continue on providing an updated patch to Riak 2.9.0 - but there should be
> no immediate concern over use of the unpatched version.
>
> Sorry for causing false alarm.
>
> Regards
>
> Martin
>
> On Thu, 22 Aug 2019 at 01:36, Martin Sumner 
> wrote:
>
>> There are 2 defects in the 2.9.0 release which should be patched within
>> the next 7 days, with a new version of 2.9.0 to be published before the end
>> of the month.  The defects are:
>>
>> https://github.com/basho/riak_kv/issues/1706
>> https://github.com/basho/riak_kv/issues/1707
>>
>> Note that the latter defect 1707, the scope of this bug is currently
>> unclear, but there exists significant risk that there is potential within
>> this bug for data loss, due to incorrect pruning of siblings.
>>
>> Previous releases of Riak also have this bug, if the metadata cache
>> (which is disabled by default) is enabled.  Enabling this cache is
>> controlled via
>> https://docs.riak.com/riak/kv/latest/configuring/reference/index.html 
>> (metadata_cache_size).
>> However, unlike previous releases the 2.9.0 release, when combined with use
>> of the leveled backend, Riak 2.9.0 will enable the path to this bug by
>> default.  This is because the logic of the metadata_cache is reused in
>> order to enable leveled HEAD requests within the PUT path.  Riak 2.9.0 with
>> other backends, and the metadata cache left disabled, will not have this
>> bug.
>>
>> I apologise for the ongoing churn of issues uncovered in release 2.9.0,
>> and for the potential risks associated with this latest bug in particular.
>> Clearly, the high rate of discovered problems has exposed that the test
>> process which surrounded this release was not good enough.  For release
>> 2.9.1 and release 3.0 the move has already been made to involve independent
>> testing organisations as a fundamental part of the development process,
>> from the start of the process.  Regardless of this, once the immediate
>> issues are patched, there is a need for some further reflection on what is
>> required to assure the safety of a release of Riak in the future.
>>
>> Regards
>>
>> Martin
>>
> ___
> 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: Riak KV 2.9.0 released at Code BEAM STO 2019

[DeadZen]

w00t! You guys rock

On Fri, May 17, 2019 at 12:27 PM Russell Brown via riak-users <
riak-users@lists.basho.com> wrote:

> Congratulations all! Great news!
>
> On 17/05/2019 16:04, Nicholas Adams wrote:
> >
> > Dear All,
> >
> > I am extremely pleased to announce with Martin Sumner at Code BEAM STO
> > 2019 that Riak KV 2.9.0 has officially been released!
> >
> > GitHub
> >
> > https://github.com/basho/riak/tree/riak-2.9.0
> >
> > Packages
> >
> > https://files.tiot.jp/riak/kv/2.9/2.9.0/
> >
> > Many thanks to everybody who contributed to this great achievement.
> >
> > As always any issues or questions, please post to GitHub, this mailing
> > list or the Slack channel.
> >
> > Best regards,
> >
> > Nicholas Adams
> >
> > Director
> >
> > TI Tokyo
> >
> > https://www.tiot.jp/en/
> >
> >
> > ___
> > 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
>
-- 
/* Sincerely
-- */
Pedram N. - CTO

It is a mistake to look too far ahead. Only one link of the chain of
destiny can be handled at a time. - Winston Churchill
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: OTP20+ and rebar3 for Riak 3.0

[DeadZen]

deadzen on skype, dead...@deadzen.com

On Mon, Feb 5, 2018 at 10:10 AM <martin@bet365.com> wrote:

> Just sorting out the logistics of this meeting with Russell - it's going
> to be done over Skype. We need to grab an email address from those who are
> wanting to join in, so we can send out the invite.
>
> As mentioned before, bet365 are keen to get Riak building on OTP20, as are
> a few others. The more users / orgs that we can get on-board, the better
> for discussion, decisions etc.
>
> Please reply with your address and we'll get it sent out.
>
> Thanks
>
> Martin
> 
> From: riak-users [riak-users-boun...@lists.basho.com] on behalf of
> martin@bet365.com [martin@bet365.com]
> Sent: 01 February 2018 11:57
> To: russell.br...@mac.com; riak-users@lists.basho.com
> Subject: RE: OTP20+ and rebar3 for Riak 3.0
>
> Just to echo what had been said on Slack already, myself and others from
> bet365 will be joining. Definitely on-board with getting the project to a
> current OTP version. Had started to look at some of the work - so it's
> going to be useful to get consensus on things such as the desire to remain
> backwards compatible etc.
>
> Thanks
>
> Martin
>
> 
> From: riak-users [riak-users-boun...@lists.basho.com] on behalf of
> Russell Brown [russell.br...@mac.com]
> Sent: 29 January 2018 21:28
> To: riak-users
> Subject: OTP20+ and rebar3 for Riak 3.0
>
> It _really_ needs doing. And a whole host of people have said they’re keen
> to work on it.
>
> Ted Burghart did a lot of work on this at Basho (talk here:
> https://www.youtube.com/watch?v=TcUTsYjEon4) and of course Heinz Gies has
> made riak_core_ng available for some time.
>
> At least 3 organisations have expressed a willingness to do the work, and
> as much as I hate meetings, I think we need to talk to get organised to get
> this done, rather than each org/individual attacking alone.
>
> I hate Wednesdays almost as much as I hate meetings, so how does 1700 GMT,
> Wednesday 7th February sound?
>
> Cheers
>
> Russell
>
>
>
> ___
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.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
> <https://maps.google.com/?q=2+Europort+Avenue,+Gibraltar=gmail=g>;
> 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 princi

Re: NHS Riak release work, update

[DeadZen]

Great news dude, Ill see if i can run it and report back.

On Thu, Nov 9, 2017 at 10:53 AM Russell Brown  wrote:

> Hi,
> I’ve spent a little time lately getting Riak’s `make test` command to
> work. I wrote about it here
>
>
> https://github.com/russelldb/russelldb.github.io/blob/master/make_test.md
>
> It includes my take on what I think we agreed the immediate road map is.
>
> Let me know if you find problems with the nhs-riak-2.2.5 branches, please.
> Or think I’m wrong about the roadmap.
>
> The riak_test runs are going well. IMO we’re on target for an end of year
> release.
>
> Cheers
>
> Russell
> ___
> 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: Riak KV performance in sensor data storage application

[DeadZen]

This looks cool, and might give some indication that back pressure
should be aware of available file system space..
Any plans on LevelDB testing? A newer option Leveled might be cool to
compare with as well.

On Tue, Oct 3, 2017 at 6:58 AM, Grigory Fateyev  wrote:
> Yury, thank you for sharing your investigations. It is very useful to read!
>
> 2017-10-03 8:32 GMT+03:00 Yury Shevchuk :
>>
>> Greetings!
>>
>> We have published a paper on the subject.  It may be of interest for
>> Riak developers and users who put Riak under heavy write load.
>>
>>   English: http://psta.psiras.ru/read/psta2017_3_61-85.pdf
>>   Russian (native): http://psta.psiras.ru/read/psta2017_3_31-60.pdf
>>
>> Best,
>>
>>
>> -- Yury
>>
>> ___
>> 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
>

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Riak and the demise of Basho

[DeadZen]

My vote as well, BSD otherwise Apache

On Sat, Sep 9, 2017 at 10:34 AM Outback Dingo <outbackdi...@gmail.com>
wrote:

> Apache2 or BSD
>
> On Thu, Sep 7, 2017 at 3:51 PM, Damien Krotkine <dam...@krotkine.com>
> wrote:
> > +1 for Apache2
> >
> > On Thu, Sep 7, 2017, at 19:05, Neeraj Sharma wrote:
> >> +1 for Apache 2. Thanks for making it open source.
> >>
> >> On Thu, Sep 7, 2017 at 3:36 AM, Bill Barnhill <w.a.barnh...@gmail.com>
> >> wrote:
> >> > +1 for Apache 2. Thank you so much for saving all the important
> technology
> >> > developed by the great developers from Basho.
> >> >
> >> > On Wed, Sep 6, 2017 at 5:31 PM, Heinz N. Gies <he...@licenser.net>
> wrote:
> >> >>
> >> >> +1 For Apache 2 :)
> >> >>
> >> >> On 6. Sep 2017, at 20:27, Jordan West <jorda...@gmail.com> wrote:
> >> >>
> >> >> Really excited to see this news. Thanks Bet365! +1 to apache2.
> >> >>
> >> >> Jordan
> >> >>
> >> >> --
> >> >> Sent from my iPhone
> >> >>
> >> >> On September 6, 2017 at 10:46:50 AM, AJAX DoneBy Jack (
> ajaxd...@gmail.com)
> >> >> wrote:
> >> >>>
> >> >>> +2 Apache 2
> >> >>>
> >> >>> On Wed, Sep 6, 2017 at 1:45 PM Bryan Hunt <ad...@binarytemple.co.uk
> >
> >> >>> wrote:
> >> >>>>
> >> >>>> +1 Apache 2
> >> >>>>
> >> >>>>
> >> >>>> On Wed, 6 Sep 2017, 18:09 Tom Santero <tsant...@gmail.com> wrote:
> >> >>>>>
> >> >>>>> +1 Apache 2
> >> >>>>>
> >> >>>>> On Wed, Sep 6, 2017 at 11:10 AM, Gokhan Boranalp <
> gok...@zetaops.io>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>> +1 for Apache 2
> >> >>>>>> i wish we could use GPL 3 :(
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Sep 6, 2017 4:55 PM, "Drew Kerrigan" <d...@kerrigan.io>
> wrote:
> >> >>>>>>>
> >> >>>>>>> +1 to Apache 2 for MDC and other relevant EE repos.
> >> >>>>>>>
> >> >>>>>>> On Wed, Sep 6, 2017 at 9:02 AM DeadZen <dead...@deadzen.com>
> wrote:
> >> >>>>>>>>
> >> >>>>>>>> Sept 16 is software freedom day, a release that day might be a
> nice
> >> >>>>>>>> idea.
> >> >>>>>>>>
> >> >>>>>>>> On Wed, Sep 6, 2017 at 8:37 AM, Christopher Meiklejohn
> >> >>>>>>>> <christopher.meiklej...@gmail.com> wrote:
> >> >>>>>>>> > Given that all of the code except for MDC (and maybe JMX) is
> under
> >> >>>>>>>> > Apache 2, I would assume that those components would follow
> the
> >> >>>>>>>> > already existing license of the other components.
> >> >>>>>>>> >
> >> >>>>>>>> > Is there a plan to change the original license on the open
> source
> >> >>>>>>>> > product from Apache 2?
> >> >>>>>>>> >
> >> >>>>>>>> > Thanks,
> >> >>>>>>>> > Christopher
> >> >>>>>>>> >
> >> >>>>>>>> > On Wed, Sep 6, 2017 at 2:13 PM,  <andrew.de...@bet365.com>
> wrote:
> >> >>>>>>>> >> Hi,
> >> >>>>>>>> >>
> >> >>>>>>>> >> A quick status update. Today bet365 have signed the
> agreement to
> >> >>>>>>>> >> purchase all Basho IP. We expect the agreement to be
> ratified in the US
> >> >>>>>>>> >> courts next week. Once cleared, our intention is to open
> source all code,
> >> >>>>>>>> >> help rebuild the community and collaboratively take the
> development of RIAK
> >> >>>>>>>> >> forward.
> >> >>>>>>

Re: Riak and the demise of Basho

[DeadZen]

Sept 16 is software freedom day, a release that day might be a nice idea.

On Wed, Sep 6, 2017 at 8:37 AM, Christopher Meiklejohn
 wrote:
> Given that all of the code except for MDC (and maybe JMX) is under
> Apache 2, I would assume that those components would follow the
> already existing license of the other components.
>
> Is there a plan to change the original license on the open source
> product from Apache 2?
>
> Thanks,
> Christopher
>
> On Wed, Sep 6, 2017 at 2:13 PM,   wrote:
>> Hi,
>>
>> A quick status update. Today bet365 have signed the agreement to purchase 
>> all Basho IP. We expect the agreement to be ratified in the US courts next 
>> week. Once cleared, our intention is to open source all code, help rebuild 
>> the community and collaboratively take the development of RIAK forward.
>>
>> In the coming weeks we will hopefully answer the questions people have and 
>> will be calling on the community to help forge the initial RIAK Roadmap.
>>
>> One of the initial questions we have for the community is which OSS license 
>> would people like applied to the code? Our thought is the most open and 
>> permissive.
>>
>> Andy.
>>
>> Andrew Deane
>> Systems Development Manager - Middleware
>> Hillside (Technology) Limited
>> andrew.de...@bet365.com
>> bet365.com
>> -Original Message-
>> From: riak-users [mailto:riak-users-boun...@lists.basho.com] On Behalf Of 
>> martin@bet365.com
>> Sent: 24 August 2017 16:18
>> To: riak-users@lists.basho.com
>> Cc: Martin Davies
>> Subject: FW: Riak and the demise of Basho
>>
>> Hi
>>
>> I have been asked to forward the below message from Martin Davies, the CEO 
>> of Technology for bet365.
>>
>> Kind Regards
>>
>> Martin Cox
>> 
>> From: Martin Davies
>> Sent: 24 August 2017 16:11
>> To: Martin Cox
>> Subject: Riak and the demise of Basho
>>
>> Hi,
>> I have been wanting to make you aware for a few weeks now that we have 
>> reached an agreement, in principle, to buy all of Basho's remaining assets 
>> (except support contracts) from the receiver. Up until this afternoon, I was 
>> constrained by some confidentiality needs of the receiver and was unable to 
>> speak.
>>
>> We have agreed a price for the assets and are almost at the end of 
>> sorting out the legal agreement. Once this is complete, this will then need 
>> to be processed through the courts which, I am advised, should take a week 
>> or so.
>>
>> It is our intention to open source all of Basho's products and all of 
>> the source code that they have been working on. We'll do this as quickly as 
>> we are able to organise it, and we would appreciate some input from the 
>> community on how you would like this done.
>>
>>
>> Martin Davies
>> Chief Executive Officer - Technology
>> Hillside (Technology) Limited
>> 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; 
>> 

Re: FW: Riak and the demise of Basho

[DeadZen]

yay we won!

now we can improve the closed source stuff too!

Three cheers for bet365

On Thu, Aug 24, 2017 at 2:12 PM David Bloom  wrote:

> Thank you for saving this awesome technology.  The open source community
> is rejoicing.
>
> On Aug 24, 2017 11:18 AM,  wrote:
>
>> Hi
>>
>> I have been asked to forward the below message from Martin Davies, the
>> CEO of Technology for bet365.
>>
>> Kind Regards
>>
>> Martin Cox
>> 
>> From: Martin Davies
>> Sent: 24 August 2017 16:11
>> To: Martin Cox
>> Subject: Riak and the demise of Basho
>>
>> Hi,
>> I have been wanting to make you aware for a few weeks now that we have
>> reached an agreement, in principle, to buy all of Basho's remaining assets
>> (except support contracts) from the receiver. Up until this afternoon, I
>> was
>> constrained by some confidentiality needs of the receiver and was unable
>> to
>> speak.
>>
>> We have agreed a price for the assets and are almost at the end of
>> sorting out the legal agreement. Once this is complete, this will then
>> need
>> to be processed through the courts which, I am advised, should take a week
>> or so.
>>
>> It is our intention to open source all of Basho's products and all of
>> the source code that they have been working on. We'll do this as quickly
>> as
>> we are able to organise it, and we would appreciate some input from the
>> community on how you would like this done.
>>
>>
>> Martin Davies
>> Chief Executive Officer - Technology
>> Hillside (Technology) Limited
>> 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) Plc, (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) Plc also have places of business at Unit 

Re: Lets come together - how riak(_core) should be developed in the future?

[DeadZen]

I'm down for a chat on how to finally get our collective stuff together.
Maybe a google hangout?

On Thu, Aug 17, 2017 at 2:14 PM Gokhan Boranalp  wrote:

> Hi all,
>
> I have created a Slack channel. Here is the invitation link[1]
> I think it is better to have a quick talk beforehand in Slack to
> organize big meeting with a rest of Riak funs/lovers.
> We are ready to provide some resources and i believe lots of folks
> would like to do the same.
> It would be very efficient to organize, as fast as possible.
> For anyone missed, there is an alternate mail group[2] if this one
> ripped of suddenly.
>
>
> [1]
> https://join.slack.com/t/postriak/shared_invite/MjI4MDU2NTI0NDM1LTE1MDI5OTMxMDAtMTQzNTM3MzAwZA
> [2] https://groups.google.com/forum/#!forum/riak-users
>
> On Thu, Aug 17, 2017 at 6:51 PM, Russell Brown 
> wrote:
> > Great idea Heinz, I think speaking together is the right start.
> >
> > I’m free next week, but a key member of our team is not. I know we’re
> never going to get everyone to agree on a time, but if we could do it early
> the following week it would suit more. Otherwise, I will attend and pass
> info along, so don’t worry. I think bet365 should be involved too. They
> probably have the largest team anywhere working on Riak.
> >
> > Maybe a doodle http://doodle.com/en_GB/ would be a good thing?
> >
> > Russell
> >
> > On 17 Aug 2017, at 15:47, Heinz N. Gies  wrote:
> >
> >> Heya everyone,
> >> I figured I’ll pick up the initiative here and see if we all can come
> together before fragmentation hits. Annette mentioned this today and I
> think she’s right.
> >>
> >> There are many people that want to see risk(_core) continue to evolve
> and improve, out of the top of my head there are ES - who picked up support
> for riak, NHS/UK - which is using it and seem to keep doing so, there is
> Gordon, Annette, Chris, Tristan, Mariano and me who all have an interest to
> keep things going. I’m pretty sure I forgot a good few people (sorry! It
> doesn’t mean I love you any less, I just have a brain like a sieve).
> >>
> >> Amongst all of us I’m sure we’ve quite some forks. Tristan, Chris,
> Mariano and me started https://github.com/Kyorai to consolidate the git
> repos that correspond to the current hex packages as an example, NHS runs a
> fork of core at https://github.com/ramensen/riak_core and I guess ES will
> have one too by now. (Again apologies if I forgot someone).
> >>
> >> I am quite sure that all of us have the same goal and probably are
> interested in the same things (keeping riak(_core) strong). So what I’d
> like to suggest is we find a time to sit together and chat about how we
> pool resources instead of trying to cross merge in N different places.
> Perhaps late next week EU afternoon US morning? Please raise a hand if
> interested, discuss and share times that would work for you :)
> >>
> >> Cheers,
> >> Heinz
> >> ___
> >> 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
>
>
>
> --
> Iyi calismalar dilerim.
> -
> Gokhan Boranalp
> +90 555 548 56 18
> gokhan.boran...@zetaops.io
> http://www.zetaops.io
> http://dc.zetaops.io/
> http://www.slideshare.net/kunthar
> http://www.github.com/kunthar
> http://www.github.com/zetaops
>
> Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen
> gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden
> siliniz.
> If you are not the intended recipient, please immediately notify the
> sender and delete the message from your system.
> -
>
> ___
> 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: Riak Core Claim Bug Fixes

[DeadZen]

You the man!

On Thu, Aug 17, 2017 at 12:06 PM Christopher Meiklejohn <
christopher.meiklej...@gmail.com> wrote:

> Bravo!
>
> On Thu, Aug 17, 2017 at 3:11 AM, Russell Brown 
> wrote:
> > Hi,
> > I wrote up a blog post about two fixes to riak_core_claim made by/with
> > NHS-Digital.
> >
> >
> https://github.com/ramensen/riak_core/blob/rdb/rs-claim-tail-violations/docs/claim-fixes.md
> >
> > This work follows on from Martin Sumner's post to the list about the
> > discovery of these issues and some potential fixes
> >
> https://github.com/infinityworks/riak_core/blob/mas-claimv2issues/docs/ring_claim.md
> > back in May of this year.
> >
> > TL:DR :-
> > Claim no longer generates rings with avoidable tail violations and
> > unbalanced vnode distributions.
> >
> > We're still figuring out the best way to release these as part of a Riak
> > build.
> >
> > Cheers
> >
> > Russell
> >
> > ___
> > 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
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Alternative email list for riak-users@lists.basho.com as basho.com will be sold

[DeadZen]

Hi I setup a sync of the basho repos in github.com/bashosync and the docs
should be in there. I copied labs as well on which I should still have some
access. Let's talk some more on setting up stuff.

On Wed, Aug 16, 2017 at 2:07 PM Gokhan Boranalp  wrote:

> Source is in github[1] but i am not sure if it is in sync with a current
> site.
> I've also wget'ed them. Around 512MB.
> In short, anyone wanna help, could ping me to talk about setup things.
>
>
>
> [1] https://github.com/basho/basho_docs
>
> On Wed, Aug 16, 2017 at 8:33 PM, Christopher Meiklejohn
>  wrote:
> > Does someone actually have the source code for the documentation and
> > know how to generate it?
> >
> > Christopher
> >
> > On Wed, Aug 16, 2017 at 3:57 AM, Steve Roberts
> >  wrote:
> >> Hi All
> >>
> >> With Basho going into bankruptcy, the domain basho.com is an asset
> which is
> >> up for sale.   This email list is hosted on the basho.com domain so
> may stop
> >> working unexpectedly in the future.
> >>
> >> We've set up an alternative email group on Google at
> >> https://groups.google.com/forum/#!forum/riak-users
> >>
> >> There's a similar issue with docs.basho.com which we hope to find a
> solution
> >> for.
> >>
> >> Steve
> >>
> >>
> >> --
> >> Regards
> >> Steve Roberts
> >> +44-7887-852-920
> >>
> >>
> >> ___
> >> 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
>
>
>
> --
> Iyi calismalar dilerim.
> -
> Gokhan Boranalp
> +90 555 548 56 18
> gokhan.boran...@zetaops.io
> http://www.zetaops.io
> http://dc.zetaops.io/
> http://www.slideshare.net/kunthar
> http://www.github.com/kunthar
> http://www.github.com/zetaops
>
> Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen
> gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden
> siliniz.
> If you are not the intended recipient, please immediately notify the
> sender and delete the message from your system.
> -
>
> ___
> 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: Is Riak dead?

[DeadZen]

Lloyd, I too have a great distaste for the cost of those things.

I don't believe that's how developers should be forced to climb the
ladder for knowledge.
Nor do I believe developers should be pushed to create most of the
content for those conferences just to be able to afford attending.

I definitely share your reservations in this regard... I was just not
compelled to state it as such until you brought it up, I have never
and will likely never attend one.

I believe the Academy needs to go along with any effort to recover
this project, and I think the material should be open source as well.



On Sat, Jul 15, 2017 at 11:41 AM, Lloyd R. Prentice
 wrote:
> Hi Steve,
>
> Many thanks for your informative and comforting post. The program you're 
> contemplating sounds sensible and, indeed, promising.
>
> Successful implementation and operation of Riak among enterprise users is in 
> everyone's interest. Erlang Solutions has an excellent track record in 
> support of Erlang. No doubt it would be a fine champion and conservator of 
> open source Riak.
>
> As an army-of-one-developer, with big dreams of an Erlang-based product,  I 
> do have one concern.
>
> I'm totally dependent on web-based documentation, tutorials, and the good 
> graces of folks on the mailing lists. As much as I'd like to attend Erlang 
> Solutions conferences and training sessions, they're priced far beyond my 
> budget.
>
> So, I do hope that in your support of Riak you don't forget that there are 
> indie developers with considerable interest in Erlang and Riak who, lacking 
> corporate backing and travel allowances, simply can't afford your enterprise 
> offerings.
>
> Beyond that, you have my vote and support in anyway within my means.
>
> All the best,
>
> Lloyd
> Writersglen Publications
>
> Sent from my iPad
>
>> On Jul 15, 2017, at 4:22 AM, Steve Roberts 
>>  wrote:
>>
>> Hi All
>>
>> Great to see there is so much enthusiasm for Riak.
>>
>> I'm from Erlang Solutions. Just to clarify where things are at the moment. 
>> The company Basho Technologies still exists - it hasn't filed for bankruptcy 
>> yet - although we expect it to. There is no grave just yet.  We are 
>> creditors and shareholders so we will be notified when/if they do file for 
>> bankruptcy.  Assuming it goes into liquidation, the receiver will sell 
>> whatever assets can be liquidated in order to pay the creditors.   
>> Registered names like Riak are things which can be sold... so we will see. 
>> it will probably take a long time before Basho is truly dead and buried.
>>
>> I've asked our CEO  Stuart Whitfield (who happens to be a lawyer) to look at 
>> the legal questions and give a more detailed view.
>>
>> As Russell correctly points out existing customers are the priority.  In 
>> terms of our thoughts of this situation, our priority is to ensure 
>> enterprise customers have continuity of support since they are the ones most 
>> likely to abandon Riak as it will be a forced migration situation if there 
>> is no support. I expect to  launch a paid support service very shortly  -  
>> if you're interested, let me know.
>>
>> In terms of Riak software, the open source software is safe since it is open 
>> sourced under a friendly licence.  The situation with the code for the 
>> enterprise version is not clear yet (highly dependent who/if it is bought in 
>> the fire sale since it is closed source) - although we aim, one way or 
>> another, to have an open source data centre replication layer. Not sure who 
>> is using the other functionality like super clusters in the the enterprise 
>> version - ping me if you are.
>>
>> In terms of the products, KV is the priority for support followed by CS/S2.  
>> There aren't many people using TS so it will probably be community support 
>> for the code. I already have some interest from a former developer  to move 
>> TS forward - if others want to work on TS I can help co-ordinate in the 
>> interim.
>>
>> In terms of evolving the code we're happy to co-ordinate a community and 
>> help steer the future direction for the product.  We are looking whether 
>> this should be done through a similar model to the Linux foundation.
>>
>> For major feature development, our thoughts are some kind of crowd funding 
>> model for functionality which requires significant development effort - 
>> Basho funded this activity through support and being closed source which 
>> doesnt really work in a completely open source model.  Our goal would be to 
>> have just the open source version and no closed source code. Where possible 
>> we wouldnt want customers to have closed source forks.
>>
>> We definitely see Riak has a future and want to focus on getting back to 
>> basics of a product which is high performance and does it well - before 
>> adding lots of new functionality. For example ensure there is a clean 
>> demarcation between the data layer and the control layer - 

Re: Is Riak dead?

[DeadZen]

Riak was and still is a good platform, with the potential to be a
great platform.
I am fairly sure I am not the only one whose staked their reputation
on it.. The name is unimportant.

The question now is where is the focus going to be put next?

To ferret away whatever existing possibly panicking customers that
were abandoned during this transition or
to improve the platform so that it can reach it's potential;
benefiting from people experienced with what it is, what it was trying
to be, and where it was trying to go.
I still think this platform can be a business advantage while
simultaneously being the ladder that engineers can use to climb up and
participate in a difficult field.

As an open source product, everyone can see where it is, it is likely
better than the closed sourced portion of the product even.
As distributed systems programmers many of us knew and were excited
about areas where it could be improved. I often pointed directly
towards Riak Core.
As a business I am fairly certain not even Basho had an idea of where
it was actually trying to go...
I kinda think a lack of organization and priority in the latter two
pegs caused the Basho stool to finally fall down.

Basho created an internal group called Taishi which was in my hopes a
sounding board for the community in a deputized fashion within Basho,
where improvements could be discussed and implemented with assistance
from developers from around the world, but besides being given a
very nice hat and couple glasses, I did not see this materialize at all.

The direction and leadership won't materialize overnight, but at least
the conversation has really started,
I am sure there is some damage control that needs to be done as well
as I believe some customers included governments and hospitals.

I see a future in an Erlang based defacto standard for an open source
implementation of the Amazon Dynamo Paper.
I see this effort being multidisciplinary as Riak ran up against
several issues, many in Erlang itself,
recall github.com/basho/otp being a fork of the entire language distribution.

ESL could possibly be a good steward here, but there are many things
that need serious consideration.

I am motivated to talk more about this.

On Sat, Jul 15, 2017 at 4:22 AM, Steve Roberts
 wrote:
> Hi All
>
> Great to see there is so much enthusiasm for Riak.
>
> I'm from Erlang Solutions. Just to clarify where things are at the moment.
> The company Basho Technologies still exists - it hasn't filed for bankruptcy
> yet - although we expect it to. There is no grave just yet.  We are
> creditors and shareholders so we will be notified when/if they do file for
> bankruptcy.  Assuming it goes into liquidation, the receiver will sell
> whatever assets can be liquidated in order to pay the creditors.
> Registered names like Riak are things which can be sold... so we will see.
> it will probably take a long time before Basho is truly dead and buried.
>
> I've asked our CEO  Stuart Whitfield (who happens to be a lawyer) to look at
> the legal questions and give a more detailed view.
>
> As Russell correctly points out existing customers are the priority.  In
> terms of our thoughts of this situation, our priority is to ensure
> enterprise customers have continuity of support since they are the ones most
> likely to abandon Riak as it will be a forced migration situation if there
> is no support. I expect to  launch a paid support service very shortly  -
> if you're interested, let me know.
>
> In terms of Riak software, the open source software is safe since it is open
> sourced under a friendly licence.  The situation with the code for the
> enterprise version is not clear yet (highly dependent who/if it is bought in
> the fire sale since it is closed source) - although we aim, one way or
> another, to have an open source data centre replication layer. Not sure who
> is using the other functionality like super clusters in the the enterprise
> version - ping me if you are.
>
> In terms of the products, KV is the priority for support followed by CS/S2.
> There aren't many people using TS so it will probably be community support
> for the code. I already have some interest from a former developer  to move
> TS forward - if others want to work on TS I can help co-ordinate in the
> interim.
>
> In terms of evolving the code we're happy to co-ordinate a community and
> help steer the future direction for the product.  We are looking whether
> this should be done through a similar model to the Linux foundation.
>
> For major feature development, our thoughts are some kind of crowd funding
> model for functionality which requires significant development effort -
> Basho funded this activity through support and being closed source which
> doesnt really work in a completely open source model.  Our goal would be to
> have just the open source version and no closed source code. Where possible
> we wouldnt want customers to have closed source 

Re: Is Riak dead?

[DeadZen]

Rackspace has provided some resources, love all the feedback.

On Thu, Jul 13, 2017 at 6:01 PM Outback Dingo 
wrote:

> I know it was, i saw the smile :) and VMS doesnt run only on alphas
> anymore :) I have both Alpha and Itaniums with OpenVMS on it live
> now.
>
> On Thu, Jul 13, 2017 at 5:57 PM, Russell Brown 
> wrote:
> >
> > On 13 Jul 2017, at 22:52, Christopher Meiklejohn <
> christopher.meiklej...@gmail.com> wrote:
> >
> >> It was a joke. :)
> >
> > Always better explained. (https://en.wikipedia.org/wiki/DEC_Alpha)
> >
> >>
> >> On Thu, Jul 13, 2017 at 2:29 PM, Outback Dingo 
> wrote:
> >> VMS as in Virtual Machine(S)
> >>
> >> On Thu, Jul 13, 2017 at 5:01 PM, Christopher Meiklejohn <
> christopher.meiklej...@gmail.com> wrote:
> >> VMS?  I don't think we ever got Riak compiling on Alpha. 
> >>
> >> On Jul 13, 2017 1:30 PM, "Outback Dingo" 
> wrote:
> >> I dont believe abandon is the proper term, resurrect and carry forth,
> >> we will not let you go quietly into the night
> >>
> >> LETS DO THIS SHIT! Ive got cloud resources I own... servers/VMS/XEN
> >> Ill do it myself if I need tooo.
> >>
> >> On Thu, Jul 13, 2017 at 4:24 PM, Alexander Sicular 
> wrote:
> >> > Abandon hope all ye who enter here.
> >> >
> >> > On Thu, Jul 13, 2017 at 3:15 PM, Tom Santero 
> wrote:
> >> >> RICON: A New Hope
> >> >>
> >> >> On Thu, Jul 13, 2017 at 4:00 PM, Russell Brown <
> russell.br...@mac.com>
> >> >> wrote:
> >> >>>
> >> >>> We have talked about it. Let's do it!
> >> >>>
> >> >>> On Jul 13, 2017 7:56 PM, ll...@writersglen.com wrote:
> >> >>>
> >> >>> Hmmm--- I wonder if anyone has given thought to a conference
> focused on
> >> >>> the future of open-source Riak?
> >> >>>
> >> >>>
> >> >>>
> >> >>> I'm sure there are many good ideas out there re: roadmap and
> governance.
> >> >>>
> >> >>>
> >> >>>
> >> >>> It's just too great not to be worth deep thought and prudent action.
> >> >>>
> >> >>>
> >> >>>
> >> >>> All the best,
> >> >>>
> >> >>>
> >> >>>
> >> >>> LRP
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> -Original Message-
> >> >>> From: "Russell Brown" 
> >> >>> Sent: Thursday, July 13, 2017 12:40pm
> >> >>> To: "Senthilkumar Peelikkampatti" 
> >> >>> Cc: "riak-users" 
> >> >>> Subject: Re: Is Riak dead?
> >> >>>
> >> >>> Hi Senthilkumar,
> >> >>> No Riak is not dead. It’s parent company, Basho is dead. And they
> kept the
> >> >>> keys. There are numerous forks that are being worked on. Hopefully
> something
> >> >>> that is a canonical, community backed fork will emerge. Past
> mailing list
> >> >>> posts show strong support from large commercial and govt.
> organisations.
> >> >>> Riak is open source and will continue to be critical infrastructure
> for
> >> >>> numerous organisation in its niche for some time.
> >> >>>
> >> >>> There are also a few support organisations springing up, as well as
> the
> >> >>> existing partners (Erlang Solutions, Trifork etc.) If you’re asking
> me, this
> >> >>> could be a very good thing for Riak in the medium to long term. It
> and it’s
> >> >>> users and community were served very badly by Basho these last
> couple of
> >> >>> years. It’s a little trodden under, but no way dead. Give it a
> little time
> >> >>> to bounce back.
> >> >>>
> >> >>> Cheers
> >> >>>
> >> >>> Russell
> >> >>>
> >> >>>
> >> >>> On 11 Jul 2017, at 08:15, Senthilkumar Peelikkampatti
> >> >>>  wrote:
> >> >>>
> >> >>> > Is Riak dead? No new activities on Riak GitHub repo.
> >> >>> >
> >> >>> > https://github.com/basho/riak_kv/pulse/monthly
> >> >>> > https://github.com/basho/riak/pulse/monthly
> >> >>> >
> >> >>> > Thanks,
> >> >>> > Senthil
> >> >>> > ___
> >> >>> > 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
> >> >>>
> >> >>>
> >> >>>
> >> >>> ___
> >> >>> 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
> >> >>
> >> >
> >> > ___
> >> > riak-users mailing list
> >> > riak-users@lists.basho.com
> >> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >>
> >> 

Re: Is Riak dead?

[DeadZen]

Awesome! Ill forward details to here for a new fork, mailing list and
academy.


On Thu, Jul 13, 2017 at 1:41 PM Outback Dingo <outbackdi...@gmail.com>
wrote:

> as I am also ready to pitch in
>
> On Thu, Jul 13, 2017 at 1:38 PM, DeadZen <dead...@deadzen.com> wrote:
> > I am willing to start this asap
> >
> > On Thu, Jul 13, 2017 at 12:59 PM Russell Brown <russell.br...@icloud.com
> >
> > wrote:
> >>
> >> Agree.
> >>
> >> But at the moment they’re also not dead. Somewhat of a zombie, rumoured
> to
> >> be litigious. Circumspection is required.
> >>
> >> It’ll happen. Don’t worry.
> >>
> >> On 13 Jul 2017, at 17:51, Outback Dingo <outbackdi...@gmail.com> wrote:
> >>
> >> > well, if thats the case someone best be starting a new site and
> >> > mailing list soon in case this one dissappears
> >> >
> >> > On Thu, Jul 13, 2017 at 12:40 PM, Russell Brown
> >> > <russell.br...@icloud.com> wrote:
> >> >> Hi Senthilkumar,
> >> >> No Riak is not dead. It’s parent company, Basho is dead. And they
> kept
> >> >> the keys. There are numerous forks that are being worked on.
> Hopefully
> >> >> something that is a canonical, community backed fork will emerge.
> Past
> >> >> mailing list posts show strong support from large commercial and
> govt.
> >> >> organisations. Riak is open source and will continue to be critical
> >> >> infrastructure for numerous organisation in its niche for some time.
> >> >>
> >> >> There are also a few support organisations springing up, as well as
> the
> >> >> existing partners (Erlang Solutions, Trifork etc.) If you’re asking
> me, this
> >> >> could be a very good thing for Riak in the medium to long term. It
> and it’s
> >> >> users and community were served very badly by Basho these last
> couple of
> >> >> years. It’s a little trodden under, but no way dead. Give it a
> little time
> >> >> to bounce back.
> >> >>
> >> >> Cheers
> >> >>
> >> >> Russell
> >> >>
> >> >>
> >> >> On 11 Jul 2017, at 08:15, Senthilkumar Peelikkampatti
> >> >> <sendto...@gmail.com> wrote:
> >> >>
> >> >>> Is Riak dead? No new activities on Riak GitHub repo.
> >> >>>
> >> >>> https://github.com/basho/riak_kv/pulse/monthly
> >> >>> https://github.com/basho/riak/pulse/monthly
> >> >>>
> >> >>> Thanks,
> >> >>> Senthil
> >> >>> ___
> >> >>> 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
> >>
> >>
> >> ___
> >> 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: Is Riak dead?

[DeadZen]

I am willing to start this asap

On Thu, Jul 13, 2017 at 12:59 PM Russell Brown 
wrote:

> Agree.
>
> But at the moment they’re also not dead. Somewhat of a zombie, rumoured to
> be litigious. Circumspection is required.
>
> It’ll happen. Don’t worry.
>
> On 13 Jul 2017, at 17:51, Outback Dingo  wrote:
>
> > well, if thats the case someone best be starting a new site and
> > mailing list soon in case this one dissappears
> >
> > On Thu, Jul 13, 2017 at 12:40 PM, Russell Brown
> >  wrote:
> >> Hi Senthilkumar,
> >> No Riak is not dead. It’s parent company, Basho is dead. And they kept
> the keys. There are numerous forks that are being worked on. Hopefully
> something that is a canonical, community backed fork will emerge. Past
> mailing list posts show strong support from large commercial and govt.
> organisations. Riak is open source and will continue to be critical
> infrastructure for numerous organisation in its niche for some time.
> >>
> >> There are also a few support organisations springing up, as well as the
> existing partners (Erlang Solutions, Trifork etc.) If you’re asking me,
> this could be a very good thing for Riak in the medium to long term. It and
> it’s users and community were served very badly by Basho these last couple
> of years. It’s a little trodden under, but no way dead. Give it a little
> time to bounce back.
> >>
> >> Cheers
> >>
> >> Russell
> >>
> >>
> >> On 11 Jul 2017, at 08:15, Senthilkumar Peelikkampatti <
> sendto...@gmail.com> wrote:
> >>
> >>> Is Riak dead? No new activities on Riak GitHub repo.
> >>>
> >>> https://github.com/basho/riak_kv/pulse/monthly
> >>> https://github.com/basho/riak/pulse/monthly
> >>>
> >>> Thanks,
> >>> Senthil
> >>> ___
> >>> 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
>
>
> ___
> 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: Udon - mrallen1 (Mark Allen) · GitHub

[DeadZen]

1. Yes, A lot of people use haproxy for this.
2. Would be a simple reimplementation of the get/put coordinators from riak

On Sun, Jul 9, 2017 at 5:24 PM, Russell Brown  wrote:
>
> On 9 Jul 2017, at 21:54, Lloyd R. Prentice  wrote:
>
>> Hello,
>>
>> Just finished viewing Mark Allen's excellent 2015 Riak Core presentation and 
>> have been reviewing his Udon code on GitHub.
>>
>> https://github.com/mrallen1
>>
>> Now I have two Micky-the-Dunce questions:
>>
>> 1. Assuming a web-based system similar to Udon on a cluster of five physical 
>> cores with data distributed across three virtual nodes, can one enter and 
>> access the data through any one of the five physical nodes?
>>
>> In other words, can one put a load balancer in front of the five physical 
>> nodes to enter and access data regardless of where it's ultimately stored in 
>> the cluster?
>
> Yes, usually the node that handles the request has access to both the ring (a 
> routing table/mapping of partitions to nodes) and the hash function.
>
>>
>> 2. Can KV functionality be relatively easily built on top of Udon--- 
>> providing storage of, say, Erlang terms as well as files?
>
> I haven’t looked at Udon, but a KV store on riak core is a very common thing. 
> There are quite a few examples out there, the largest (and most complex) 
> being Riak itself https://github.com/basho/riak
>
>>
>> Thanks to all,
>>
>> LRP
>>
>>
>> Sent from my iPad
>>
>> ___
>> 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

___
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

[DeadZen]

I'd like to keep the core project going, just depends on how much interest
there is.
There are a lot of separate issues and stalled initiatives, if anyone likes
to discuss them. Some have to do simply with scaling Distributed Erlang.
Theres a riak core mailing list as well that probably could use some fresh
air.

Thanks,
Pedram

On Tue, May 16, 2017 at 3:29 PM Christopher Meiklejohn <
christopher.meiklej...@gmail.com> wrote:

> We're looking at mainly leveraging partisan for changing the
> underlying communication structure -- we hope to have via support in
> Partisan soon along with connection multiplexing, so we hope to avoid
> bottlenecks related to head-of-line-blocking in distributed Erlang, be
> able to support SSL/TLS easier for intra-cluster communication and
> have more robust visibility into how the cluster is operating.
>
> One thing we learned from Riak MDC is that the single connection's
> used in distributed Erlang are a bottleneck and difficult to apply
> flow and congestion control to -- where, we believe a solution based
> completely on gen_tcp would be more flexible.
>
> [Keep in mind this is a ~1 year vision at the moment.]
>
> Thanks,
> - Christopher
>
> On Tue, May 16, 2017 at 9:20 PM, Martin Sumner
>  wrote:
> > Chris,
> >
> > Is this only the communications part, so the core concepts like the Ring,
> > preflists, the Claimant role, the claim algo etc will remain the same?
> >
> > Where's the best place to start reading about Partisan, I'm interested in
> > the motivation for changing that part of Core.  Is there a special use
> case
> > or problem you're focused on (e,g. gossip problems in much larger
> clusters)?
> >
> > Ta
> >
> > Martin
> >
> > On 16 May 2017 at 20:06, Christopher Meiklejohn
> >  wrote:
> >>
> >> For what it's worth, the Lasp community is looking at doing a fork of
> >> Riak Core replacing all communication with our Partisan library and
> >> moving it completely off of distributed Erlang.  We'd love to hear
> >> from more folks that are interested in this work.
> >>
> >> - Christopher
> >>
> >> On Tue, May 16, 2017 at 6:53 PM, Tom Santero 
> wrote:
> >> > I'm aware of a few other companies and individuals who are interested
> in
> >> > continued development and support in a post-Basho world. Ideally the
> >> > community can come together and contribute to a single, canonical
> fork.
> >> >
> >> > Semi-related, there's a good chance this mailing list won't last much
> >> > longer, either. I'm happy to personally contribute time and resources
> to
> >> > help maintain the community.
> >> >
> >> > Tom
> >> >
> >> > On Tue, May 16, 2017 at 11:51 AM, Martin Sumner
> >> >  wrote:
> >> >>
> >> >>
> >> >> I've raised an issue with Core today
> >> >> (https://github.com/basho/riak_core/issues/908), related to the
> claim
> >> >> algorithms.
> >> >>
> >> >> There's a long-read associated with this, which provides a broader
> >> >> analysis of how claim works with the ring:
> >> >>
> >> >>
> >> >>
> >> >>
> https://github.com/martinsumner/riak_core/blob/mas-claimv2issues/docs/ring_claim.md
> >> >>
> >> >> I believe the long-read explains some of the common mysterious issues
> >> >> which can occur with claim.
> >> >>
> >> >> We're in the process of fixing up the property-based tests for
> >> >> riak_core_claim.erl, and will then be looking to make some
> improvements
> >> >> to
> >> >> claim v2 to try and pass the improved tests.
> >> >>
> >> >> Big question is though, how can we progress any contribution we make
> >> >> into
> >> >> the Riak codebase?  What is the plan going forward for open-source
> >> >> contributions to Riak?  Do Basho have any contingency plans for
> >> >> smoothly
> >> >> handing over open-source code to the community, before the list of
> >> >> Basho's
> >> >> Github people (https://github.com/orgs/basho/people) who still work
> at
> >> >> Basho
> >> >> is reduced to zero?
> >> >>
> >> >> Is this something of concern to others?
> >> >>
> >> >> Regards
> >> >>
> >> >> Martin
> >> >>
> >> >>
> >> >> ___
> >> >> 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
> >> >
> >
> >
>
> ___
> 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: How Riak Handle Request?

[DeadZen]

I don't see that being alluded to.. An erlang vm, which occupies an os
process runs an instance of the riak application, with a configurable
number of asynchronous threads for io and schedulers for processes
which are internal to erlang, this can be any number of hundreds of
thousands of "light processes". Erlang is inherently SMP friendly, as
processes hardly ever share memory, the non SMP portions are also
going away iirc. Erlangs os pid hosts many erlang processes, these
processes naturally are multiprocessor friendly, the schedulers should
be configured to align with your available processor cores.

On Tue, Apr 18, 2017 at 9:16 AM, Carlo Pires  wrote:
> Fred,
>
> Are you saying that Riak doesn't start erlang runtime in SMP and a machine
> with multiple processes will have only one dedicated to each Riak instance?
>
> 2017-04-17 23:43 GMT-03:00 Fred Dushin :
>>
>> What do you mean by 'process'?
>>
>> If you mean operating system process, then, No.  A Riak instance runs in a
>> single OS process.  There is a Riak instance per "node" in the cluster,
>> where a "node" is a machine, container, etc.  Probably what the OMG guys
>> used to call a "capsule"  (cute)  There are typically many nodes in a Riak
>> cluster; hence multiple OS processes, but in general it only makes sense to
>> run each process on a separate node or machine, because things break.
>>
>> If you mean a lightweight Erlang process, then yes, there is an Erlang
>> process per connection.  From that point on, it gets ... complicated.  There
>> are process corresponding to coordinating finite state machines, processes
>> (plural) corresponding to vnodes, and there is a long list of processes that
>> run support for all things between.  But all of these Erlang processes (or
>> "actors") run in a single operating system process, the Erlang virtual
>> machine, or abstract machine, if you learned how to computer before Java.
>>
>> Does that help?
>>
>> -Fred
>>
>> > On Apr 17, 2017, at 9:19 PM, Jing Liu  wrote:
>> >
>> > Hey,
>> >
>> > I'm specifically concerned about connection reading, data sending,
>> > data encoding and decoding. Is that done by a single process, a
>> > fixed-size process pool or does Riak spawns a new process for every
>> > incoming request/connection?
>> >
>> > Thanks very much !
>> > Jing
>> >
>> > On Mon, Apr 17, 2017 at 12:36 PM, Christopher Meiklejohn
>> >  wrote:
>> >> On Sat, Apr 15, 2017 at 2:16 PM, Jing Liu  wrote:
>> >>> Hi, I'm learning Riak. I'm wondering that if this is the case that on
>> >>> each physical node, a single process is reading the connection,
>> >>> decoding the buffer, spawning a new process to process the request and
>> >>> then be able to handle next request from client?
>> >>
>> >> Hi Jing,
>> >>
>> >> Depending on what you're looking it, it might be handled differently.
>> >> Typically, a process pool is used to handle incoming requests, but
>> >> processing of the request itself is handled by several processes that
>> >> operate concurrently.
>> >>
>> >> What specific operation are you referring to?
>> >>
>> >> Thanks,
>> >> Christopher
>> >
>> > ___
>> > 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
>
>
>
>
> --
>   Carlo Pires
>
> ___
> 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: Leveled - Another Erlang Key-Value store

[DeadZen]

Cheers indeed!
You added HEAD requests so a full GET wouldn't always be required?
Did I read that right? *dives into code*
%% GET requests first follow the path of a HEAD request, and if an object is
%% found, then fetch the value from the Journal via the Inker.
... WHAT?

Very nice work, will be more than happy to provide feedback and patches on this.

On Tue, Feb 28, 2017 at 9:04 AM, Martin Sumner
 wrote:
>
> Over the past few months I've been working on an alternative pure-Erlang
> Key/Value store to act as a backend to Riak KV.  This is now open source and
> available at
>
> https://github.com/martinsumner/leveled
>
> The store is a work-in-progress prototype, originally started to better
> understand the impact of different trade-offs in LSM-Tree design.  The aim
> is to:
>
> - provide a fully-featured Riak backend (e.g. secondary index, object expiry
> support etc)
> - provide stable throughput with larger object sizes (> 4KB)
> - provide a simpler and more flexible path to making Riak KV changes
> end-to-end
>
> The prime change in the store when compared to HanoiDB or eleveldb is that
> storage is split with only Keys & Metadata being placed in the merge tree,
> and the full object living to the side in a series of CDB-based journals.
> The intention of this is to:
>
> - reduce write amplification and ease page-cache pollution issues on
> scanning events.
> - support faster HEAD requests than GET requests, and in parallel an
> alternative Riak KV branch has been produced to move from an n-GET model to
> a n-HEAD 1-GET model of fetching data for both KV GET and KV PUT operations
>
> The impact of this has been to improve throughput for larger object sizes
> where disk I/O and not CPU is the current limit on throughput.  The
> advantage increases the greater the object size, and the tighter the
> constraint on disk.
>
> Please visit the github page, I've tried to write up as much about the
> project as I can.  There's the results of various volume tests, information
> on the research which prompted the design, an overview of the design itself
> and some hints as to what I expect to try next with leveled.
>
> Any feedback, please mail me, raise an issue on github, or ping me @masleeds
>
> Cheers
>
> Martin
>
> ___
> 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: [Basho Riak] Fail To Update Document Repeatly With Cluster of 5 Nodes

[DeadZen]

Why are they public?

On Thu, Feb 9, 2017 at 3:11 PM, Alexander Sicular  wrote:
> Speaking of timings:
>
> ring_members : ['riak-node1@64.137.190.244','riak-node2@64.137.247.82',
> 'riak-node3@64.137.162.64','riak-node4@64.137.161.229',
> 'riak-node5@64.137.217.73']
>
> Are these nodes in the same local area network?
>
> On Thu, Feb 9, 2017 at 12:49 PM, my hue  wrote:
>> Dear Russel,
>>
>> I did the simplest possible with new document and use modify_type to update
>> a single register.
>> I still meet fail update at some times.
>>
>> My steps did as follow :
>>
>> Step 1:   Initial a new document Map
>> Step 2:  Create new map with :  riakc_pb_socket:update_type(Pid,
>> {BucketType, Bucket}, Key,  riakc_map:to_op(Map), []).
>> Step 3:   Fetch to check result :
>> riakc_pb_socket:fetch_type(Pid,{BucketType,Bucket}, Key).
>> Step 4:  Create Fun for input of modify_type which update only one field of
>> map
>>
>> Fun1 = fun(OldMap) -> riakc_map:update({<<"status_id">>, register}, fun(R)
>> -> riakc_register:set(<<"show">>,  R) end, OldMap) end.
>>
>> Fun2 = fun(OldMap) -> riakc_map:update({<<"status_id">>, register}, fun(R)
>> -> riakc_register:set(<<"hide">>,  R) end, OldMap) end.
>>
>> Step 5: Update :
>>
>> riakc_pb_socket:modify_type(Pid, Fun1, {BucketType, Bucket}, Key, []).
>>
>> Fetch to check :
>>
>> riakc_pb_socket:fetch_type(Pid,{BucketType,Bucket}, Key).
>>
>> Step 6:  Update:
>>
>> riakc_pb_socket:modify_type(Pid, Fun2, {BucketType, Bucket}, Key, []).
>>
>> Fetch to check :
>>
>> riakc_pb_socket:fetch_type(Pid,{BucketType,Bucket}, Key).
>>
>>
>> For my debug and test,  I repeated step 5 and step 6 on one document about
>> 20 times.
>> And via many documents, I meet weird behaviour that some documents meet fail
>> update, and some documents never fail update.
>> The first time, I think that cause network, or timeout between nodes and
>> this is only random of fail.  So I deleted documents with command:
>>
>>  riakc_pb_socket:delete(Pid, {BucketType,Bucket}, Key, []).
>>
>> Then retest on each document of first test again. And It is very amazing
>> that the documents meet fail at first test still meet fail at this second
>> test, and the documents passed at first test still pass at this second test.
>> Delete all again, and retest and of course get the same result.
>>
>> After all I make other test case, I used one fail document at all test
>> times, and keep all fields except change key to get different documents for
>> the debug.  And very surprise that I still got some fail and some success,
>> although documents are  the same field and value except key.  Delete and
>> retest and still the same result. Documents succeeded will be always
>> succeed. And document meet fail will be always failed.  I totally do not
>> understand root cause till now. And hope that can get support and help from
>> the developers of riak.   I can tell that my system mostly fail with cluster
>> run when faced this issue.
>>
>> The following is some map documents I used on the test.  And I also attached
>> the extracted log of each node at one of the fail times together with this
>> email. I do not really get meaning of riak log but hope that can help
>> developers of riak get something.
>>
>>
>>
>> * New Document which meet fail with my steps.
>>
>> {map,[],
>>  [{{<<"account_id">>,register},
>> {register,<<>>,<<"accountqweraccountqweraccountqwer">>}},
>>   {{<<"created_by_id">>,register},
>> {register,<<>>,<<"accountqweraccountqweraccountqwer">>}},
>>   {{<<"created_time_dt">>,register},
>> {register,<<>>,<<"2017-02-7T23:49:04Z">>}},
>>   {{<<"currency">>,register}, {register,<<>>,<<"usd">>}},
>>
>> {{<<"id">>,register},{register,<<>>,<<"menu1234567812345678123456789">>}},
>>   {{<<"maintain_mode_b">>,register}, {register,<<>>,<<"false">>}},
>>   {{<<"menu_category_revision_id">>,register},
>> {register,<<>>,<<"0-634736bc14e0bd3ed7e3fe0f1ee64443">>}},
>>   {{<<"name">>,register},{register,<<>>,<<"menutest">>}},
>>   {{<<"order_id">>,register},{register,<<>>,<<"0">>}},
>>   {{<<"rest_location_p">>,register},
>> {register,<<>>,<<"10.844117421366443,106.63982392275398">>}},
>>   {{<<"restaurant_id">>,register},
>> {register,<<>>,<<"rest848e042b3a0488640981c8a6dc4a8281">>}},
>>   {{<<"restaurant_status_id">>,register}, {register,<<>>,<<"active">>}},
>>   {{<<"start_time">>,register},{register,<<>>,<<"dont_use">>}},
>>   {{<<"status_id">>,register},{register,<<>>,<<"show">>}},
>>   {{<<"updated_by_id">>,register},
>> {register,<<>>,<<"accountqweraccountqweraccountqwer">>}},
>>   {{<<"updated_time_dt">>,register},
>> {register,<<>>,<<"2017-02-7T23:49:04Z">>}}],
>>  [],undefined}.
>>
>> Key = <<"menu1234567812345678123456789">>
>>
>> * New Document which always success with my steps:
>>
>> {map,[],
>>  [{{<<"account_id">>,register},
>> {register,<<>>,<<"accountqweraccountqweraccountqwer">>}},
>>   

Re: Reg: value error in mochiglobal:compile/2 line 51

[DeadZen]

seems not actually a mochiglobal error so much as os_mon reported a system
limit. you can up some of your values in vm.args. max processes/ets table
limits/etc


On Mon,
 Jan 9, 2017 at 5:14 AM Steven Joseph  wrote:

> Hi Folks,
>
> I've started getting this error in my riak cluster almost periodically.
>
> Has anyone else encountered this before:
>
> 2017-01-09 03:36:02.293 [error] <0.7098.626> gen_server yz_cover
> terminated with reason: no match of right hand value error in
> mochiglobal:compile/2 line 51
> 2017-01-09 03:36:02.293 [error] <0.7098.626> CRASH REPORT Process yz_cover
> with 0 neighbours exited with reason: no match of right hand value error in
> mochiglobal:compile/2 line 51 in gen_server:terminate/6 line 744
> 2017-01-09 03:36:02.293 [error] <0.846.0> Supervisor yz_general_sup had
> child yz_cover started with yz_cover:start_link() at <0.7098.626> exit with
> reason no match of right hand value error in mochiglobal:compile/2 line 51
> in context child_terminated
> 2017-01-09 03:36:02.324 [error] emulator Error in process <0.26014.622> on
> node 'riak@x' with exit value:
> {{badmatch,{error,system_limit}},[{cpu_sup,get_uint32_measurement,2,[{file,"cpu_sup.erl"},{line,223}]},{cpu_sup,measurement_server_loop,1,[{file,"cpu_sup.erl"},{line,585}]}]}
>
> Thanks
>
> Steven
>
>
> ___
>
> 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: Riak CS: avoiding RAM overflow and OOM killer

[DeadZen]

ok I loled at this. then got worries trump could win a node election.

anyways. 24gigs per riak server is not a bad safe bet.
Erlang in general is ram heavy. It uses it more effectively then most
languages wrt concurrency, but ram is the fuel for concurrency and buffer
for operations, especially dumb operations involving large orange
loud-mouth objects.. as pointed out you can increase cumulative resources
by adding more physical nodes. and there is a trade off for adding more
virtual nodes. theres also an IPC trade off adding more then a few dozen
physical nodes in the same cluster. Theres also possiby a trade off using
riak ts and riak kv in the same cluster. Nothing but tradeoffs.

On Tue, Nov 22, 2016 at 12:29 PM Alexander Sicular 
wrote:

> Hi Daniel,
>
> Ya, I'm not surprised you're having issues. 4GB ram is woefully
> underspecd. 
>
> 邏Stupid math:
>
> 3e7 x 3 (replication) / 9 = 1e7 minimum objects per node ( absolutely more
> due to obj > 1MB size )
>
> 1e7 x ~400 bytes per obj in ram = 4e9 ram per node just for bitcask. Aka 4
> GB.
>
> You already hit your limit. We can stop here. Done. End of. ☠️
>
> 樂But let's continue for funzies.
>
> Assuming defaults:
>
> Default ring_size = 64 / 9 nodes ~ 7 virtual nodes per physical node.
>
> Default leveldb ram allocation = 70%
>
> Leveldb operates, aka consumes resources including ram, on a vnode basis.
> It likes to consume ram on the order of 300MB through 2.5GB per vnode,
> increasing in performance till it caps. Even if you did switch everything
> to level you'd still be redlined.
>
> Bottom line is that bitcask, leveldb and your OS are fighting for ram all
> day 'ery day. Why you hate them and make them fight like that? Not
> nice! (Trumpisms!)邏
>
> -Alexander
>
> ps. You probably want to bump to 128 ring size. More vnodes equals more
> parallelism, but also means more resource consumption. You prob want min 8
> (v)CPU and 16GB min ram. YMMV, check my math.
>
> pps. If you don't want to double your per VM cost (aws ec2, etc) you could
> add nodes to the cluster. Because Riak uniformly distributes data around
> the cluster adding nodes increase total resources to the cluster, reduces
> number of objects allocated to each node. The converse is also true, if you
> double your node size you could halve your node count. That said, systems
> like Riak like prefer more nodes. It's just a math game.
>
> @siculars
> http://siculars.posthaven.com
>
> Sent from my iRotaryPhone
>
> On Nov 22, 2016, at 08:51, Daniel Miller  wrote:
>
> Hi Alexander,
>
> Thanks for responding.
>
> > How many nodes?
>
> We currently have 9 nodes in our cluster.
>
>
>
> > How much ram per node?
>
>
> Each node has 4GB of ram and 4GB of swap. The memory levels (ram + swap)
> on each node are currently between 4GB and 5.5GB.
>
>
>
> > How many objects (files)? What is the average file size?
>
> We currently have >30 million objects, and I analyzed the average object
> size before we migrated data into the cluster it was about 4KB/object, with
> some objects being much larger (multiple MB). Is there an easy way to get
> this information from a running cluster so I can give you more accurate
> information?
>
>
> On Tue, Nov 22, 2016 at 2:42 AM, Alexander Sicular 
> wrote:
>
> Hi Daniel,
>
> How many nodes?
> -You should be using 5 minimum if you using the default config. There
> are reasons.
>
> How much ram per node?
> -As you noted, in Riak CS, 1MB file chunks are stored in bitcask.
> Their key names and some overhead consume memory.
>
> How many objects (files)? What is the average file size?
> -If your size distribution significantly skews < 1MB that means you
> will have a bunch of files in bitcask eating up ram.
>
> Kota was a former Basho engineer who worked on CS... That said, Basho
> may not support a non standard deployment.
>
> -Alexander
>
> On Mon, Nov 21, 2016 at 2:45 PM, Daniel Miller  wrote:
> > I found a similar question from over a year ago
> > (
> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2015-July/017327.html
> ),
> > and it sounds like leveldb is the way to go, although possibly not well
> > tested. Has anything changed with regard to Basho's (or anyone else)
> > experience with using leveldb backend instead of the mutli backend for
> CS?
> >
> > On Fri, Nov 4, 2016 at 11:48 AM, Daniel Miller 
> wrote:
> >>
> >> Hi,
> >>
> >> I have a Riak CS cluster up and running, and am anticipating exponential
> >> growth in the number of key/value pairs over the next few years. From
> >> reading the documentation and experience, I've concluded that the
> default
> >> configuration of CS (with riak_cs_kv_multi_backend) keeps all keys in
> RAM.
> >> The OOM killer strikes when Riak uses too much RAM, which is not good
> for my
> >> sanity or sleep. Because of the amount of growth I am anticipating, it
> seems
> >> unlikely that I can allocate enough RAM to 

Re: Seeking Backup solution for live nodes

[DeadZen]

there a backup tool that uses this yet? or is this meant more to be used
with snapshots provided through xfs/zfs?

On Monday, September 26, 2016, Matthew Von-Maszewski 
wrote:

> Here are notes on the new hot backup:
>
> https://github.com/basho/leveldb/wiki/mv-hot-backup
>
> This sound like what you need?
>
> Matthew
>
> Sent from my iPad
>
> > On Sep 26, 2016, at 5:39 AM, Niels Christian Sorensen <
> n...@corporateencryption.com > wrote:
> >
> > Hi,
> >
> > We use Riak-kv Enterprise Edition as base for Riak CS to store files in.
> Each customer has a separate bucket in the cluster(s) and all data is
> stored multi site in 3 copies. Thus the "i lost a node" situation is fully
> covered.
> >
> > I need however, a solution for providing customers with a "single
> instance" backup of their data.
> >
> > I am aware of the possibility of tar, cp, scp, what-ever-copy of the
> data - but this require me to take system off-line according to this:
> > https://docs.basho.com/riak/kv/2.1.4/using/cluster-
> operations/backing-up/
> >
> > Also I would still have to restore all customers data (and all involved
> nodes) - this is not trivial!
> >
> > Also I realize that the "riak-admin backup" is deprecated and should be
> avoided - It seemed like an easy solution to my problem but
> >
> > The s3cmd will allow me to pull out the data and I could most likely
> write a fantastic automatic script based system to use this - I do not have
> the time for that and are therefor looking for a commercial or "pre-build -
> adjustable" solution that will allow me to pull out a single copy of all
> data stored in a bucket and keep it elsewhere.
> >
> > Any ideas / solutions / quotes (as external consultant) on a solution to
> this problem?
> >
> > A plan for recovery is obviously also needed ;-)
> >
> > Thanks in advance
> >
> > /Christian
> >
> > ___
> > 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
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Operational nightmare fun: dealing with misconfigured Riak Clusters - blog post

[DeadZen]

nice post, not a big fan of the proxy design.

On Monday, September 26, 2016, Andra Dinu 
wrote:

> Hi,
>
> This post is a story about investigating a struggling Riak cluster,
> finding out why Riak's usual self-healing processes got stuck, and how our
> operations and maintenances tool WombatOAM can help with the struggle:
> https://www.erlang-solutions.com/blog/operational-nightmare-fun-
> dealing-with-misconfigured-riak-clusters.html
>
> Thanks,
> Andra
>
> *Andra Dinu*
> Community  & Social
>
>
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: app.config missing?

[DeadZen]

Nope, app.config is actually generated by riak.conf, through an
obscure process known as cuttlefishing ;p

On Mon, Sep 19, 2016 at 3:44 AM, Alex De la rosa
 wrote:
> Ok, documentation was confusing, i thought i had to add the data in both
> riak.conf and app.config
>
> Thanks,
> Alex
>
> On Mon, Sep 19, 2016 at 11:42 AM, Magnus Kessler  wrote:
>>
>> On 18 September 2016 at 07:51, Alex De la rosa 
>> wrote:
>>>
>>> Hi there,
>>>
>>> I'm trying to locate the app.config file in Riak 2.1.4-1 to add the
>>> following:
>>>
>>> { kernel, [
>>> {inet_dist_listen_min, 6000},
>>> {inet_dist_listen_max, 7999}
>>>   ]},
>>>
>>> as explained at http://docs.basho.com/riak/kv/2.1.4/using/security but I
>>> can't find it.
>>>
>>> Thanks,
>>> Alex
>>>
>>
>>
>> Hi Alex,
>>
>> With Riak 2.x we recommend using the new configuration mechanism (a.k.a
>> cuttlefish). Please use the instructions for using riak.conf on the page you
>> quoted.
>>
>> erlang.distribution.port_range.minimum = 6000
>> erlang.distribution.port_range.maximum = 7999
>>
>> For more information about Riak's configuration system, please see the
>> configuration reference documentation [0].
>>
>> Kind Regards,
>>
>> Magnus
>>
>> [0]: http://docs.basho.com/riak/kv/2.1.4/configuring/reference/
>>
>>  --
>> Magnus Kessler
>> Client Services Engineer
>> Basho Technologies Limited
>>
>> Registered Office - 8 Lincoln’s Inn Fields London WC2A 3BP Reg 07970431
>
>
>
> ___
> 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: Riak cluster protected by firewall

[DeadZen]

Looks right, jmx not imx ;),
and yes provided the erlang kernel options are given to limit dist
comm range to 6000-7999

you can check this from the node (to make sure) with:
> [ application:get_env(kernel, X) || X <- 
> [inet_dist_listen_min,inet_dist_listen_max] ].
[{ok,6000},{ok,7999}]

On Sun, Sep 18, 2016 at 2:42 AM, Alex De la rosa
 wrote:
> So mainly the ports are:
>
> epmd listener: TCP:4369
> handoff_port listener: TCP:8099
> http: TCP:8098
> protocol buffers: TCP: 8087
> solr: TCP:8093
> solr imx: TCP:8985
> erlang range: TCP:6000~7999 (if configured in riak's configuration)
>
> Is that alright? am I missing any? or is there any of them that is not
> needed to add in the firewall?
>
> Thanks,
> Alex
>
> On Sun, Sep 18, 2016 at 5:57 AM, John Daily  wrote:
>>
>> You should find most of what you need here:
>> http://docs.basho.com/riak/kv/2.1.4/using/security/
>>
>> Sent from my iPhone
>>
>> On Sep 17, 2016, at 1:26 PM, Alex De la rosa 
>> wrote:
>>
>> Hi all,
>>
>> I have a cluster of 5 nodes connected to each other and now I want to use
>> UFW to deny any  external incoming traffic into them but i will allow each
>> node to access between themselves. Which ports should i open
>> (pb_port,http_port,solr,...)? I connect via pbc but i may need more ports
>> open i guess.
>>
>> A configurations like this (assuming is node_1):
>>
>> ufw default deny incoming
>> ufw default allow outgoing
>> ufw allow 22 --> SSH (private keys)
>> ufw allow from  to any port 443 --> HTTPS (API that talks
>> with Riak locally via Python client)
>>
>> ufw allow from  to any port 
>> ufw allow from  to any port 
>> ufw allow from  to any port 
>> ufw allow from  to any port 
>>
>> Thanks!
>> Alex
>>
>> ___
>> 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
>

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Detecting Hinted Handoff

[DeadZen]

Agreed rolling your own 2i is likely your best bet here, I too am wondering
what purpose it would serve you.


On Monday, July 25, 2016, Russell Brown <russell.br...@me.com> wrote:

> But I still don’t understand _why_? What is the aim, ‘cos I’m not sure
> it’s possible.
>
> For quorum reads on indexes then Sargun’s “roll your own” idea is the
> better answer at the moment.
>
> On 25 Jul 2016, at 11:25, DeadZen <dead...@deadzen.com <javascript:;>>
> wrote:
>
> > Hinted handoff from adding a node, removing a node or failing a node?
> Could probably get some idea from a ring handler, hinted handoff could
> likely very well trigger its own event as well without a large modification
> to riak_core
> >
> >
> > On Sunday, July 24, 2016, Sargun Dhillon <sar...@sargun.me
> <javascript:;>> wrote:
> > It might also make a lot of sense to roll your own secondary indices.
> That is, have a CRDT set represent the primary key of the rows which meet
> the 2i condition. In that, you can query the CRDT set, and ensure some
> level of consistency. There are further tricks to be played here if
> interested.
> >
> > I'm curious, what is your data model?
> >
> > On Fri, Jul 22, 2016 at 11:01 AM, Alexander Sicular <sicul...@gmail.com
> <javascript:;>> wrote:
> > Take a look at the "pw" and "pr" tunable consistency options for gets
> and puts. The base level of abstraction in Riak is the virtual node - not
> the physical machine. When data is replicated it is replicated to a replica
> set of virtual nodes. Those virtual nodes have primary and secondary (due
> to failures) allocations to physical machines. When using "pr" and "pw"
> options you instruct Riak to only service the request from virtual nodes
> that are residing on their primarily allocated physical machines. In short,
> by abusing pr/pw you can infer the state of your cluster from your
> application.
> >
> > Obviously, this is not foolproof. There may also be additional 2i
> specific issues to consider. Nevertheless, I always liked this trick.
> >
> > Also, review this four part series on tunable consistency :
> >
> >
> http://basho.com/posts/technical/understanding-riaks-configurable-behaviors-part-1/
> > http://basho.com/posts/technical/riaks-config-behaviors-part-2/
> > http://basho.com/posts/technical/riaks-config-behaviors-part-3/
> > http://basho.com/posts/technical/riaks-config-behaviors-part-4/
> >
> > -Alexander
> >
> >
> > @siculars
> > http://siculars.posthaven.com
> >
> > Sent from my iRotaryPhone
> >
> > On Jul 22, 2016, at 12:28, Hawk Newton <hawk.new...@gmail.com
> <javascript:;>> wrote:
> >
> >> I've got a use case in which I'd like to use a secondary index but can't
> >> tolerate partial result sets caused by hinted handoffs.  I'm not
> currently
> >> running riak search and, as this is a fringe case, would prefer not add
> the
> >> additional overhead and complexity if I can help it.
> >>
> >> I'd like to detect a hinted handoff operation and throw a 503, if
> possible.
> >>
> >> Does anyone know of a way I can programatically detect if a hinted
> handoff
> >> is underway without having to shell out to riak-admin (yuck!) and parse
> the
> >> results? I'm running riak 2.0.5 at the moment.
> >>
> >> Thank you in advance.
> >>
> >> -- Hawk
> >>
> >>
> >>
> >> --
> >> View this message in context:
> http://riak-users.197444.n3.nabble.com/Detecting-Hinted-Handoff-tp4034489.html
> >> Sent from the Riak Users mailing list archive at Nabble.com.
> >>
> >> ___
> >> riak-users mailing list
> >> riak-users@lists.basho.com <javascript:;>
> >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >
> > ___
> > riak-users mailing list
> > riak-users@lists.basho.com <javascript:;>
> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >
> >
> > ___
> > riak-users mailing list
> > riak-users@lists.basho.com <javascript:;>
> > 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: Detecting Hinted Handoff

[DeadZen]

Hinted handoff from adding a node, removing a node or failing a node? Could
probably get some idea from a ring handler, hinted handoff could likely
very well trigger its own event as well without a large modification to
riak_core


On Sunday, July 24, 2016, Sargun Dhillon  wrote:

> It might also make a lot of sense to roll your own secondary indices. That
> is, have a CRDT set represent the primary key of the rows which meet the 2i
> condition. In that, you can query the CRDT set, and ensure some level of
> consistency. There are further tricks to be played here if interested.
>
> I'm curious, what is your data model?
>
> On Fri, Jul 22, 2016 at 11:01 AM, Alexander Sicular  > wrote:
>
>> Take a look at the "pw" and "pr" tunable consistency options for gets and
>> puts. The base level of abstraction in Riak is the virtual node - not the
>> physical machine. When data is replicated it is replicated to a replica set
>> of virtual nodes. Those virtual nodes have primary and secondary (due to
>> failures) allocations to physical machines. When using "pr" and "pw"
>> options you instruct Riak to only service the request from virtual nodes
>> that are residing on their primarily allocated physical machines. In short,
>> by abusing pr/pw you can infer the state of your cluster from your
>> application.
>>
>> Obviously, this is not foolproof. There may also be additional 2i
>> specific issues to consider. Nevertheless, I always liked this trick.
>>
>> Also, review this four part series on tunable consistency :
>>
>>
>> http://basho.com/posts/technical/understanding-riaks-configurable-behaviors-part-1/
>> http://basho.com/posts/technical/riaks-config-behaviors-part-2/
>> http://basho.com/posts/technical/riaks-config-behaviors-part-3/
>> http://basho.com/posts/technical/riaks-config-behaviors-part-4/
>>
>> -Alexander
>>
>>
>> @siculars
>> http://siculars.posthaven.com
>>
>> Sent from my iRotaryPhone
>>
>> On Jul 22, 2016, at 12:28, Hawk Newton > > wrote:
>>
>> I've got a use case in which I'd like to use a secondary index but can't
>> tolerate partial result sets caused by hinted handoffs.  I'm not currently
>> running riak search and, as this is a fringe case, would prefer not add
>> the
>> additional overhead and complexity if I can help it.
>>
>> I'd like to detect a hinted handoff operation and throw a 503, if
>> possible.
>>
>> Does anyone know of a way I can programatically detect if a hinted handoff
>> is underway without having to shell out to riak-admin (yuck!) and parse
>> the
>> results? I'm running riak 2.0.5 at the moment.
>>
>> Thank you in advance.
>>
>> -- Hawk
>>
>>
>>
>> --
>> View this message in context:
>> http://riak-users.197444.n3.nabble.com/Detecting-Hinted-Handoff-tp4034489.html
>> Sent from the Riak Users mailing list archive at Nabble.com
>> .
>>
>> ___
>> 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
>>
>>
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Retrieving objects from Riak

[DeadZen]

Definitely an excellent response from Alexander, describing the overall state

My suggestion would be to try at least two approaches and develop a
way to compare them.

   Do you want to do statistics? are the entries for those statistics
fairly immutable? it seems TS would be a good choice.
User verification could also work, with configurable levels of
consistency from KV, how much is enough?; no one but the authors of
the software can answer for sure. Without fully understanding all the
requirement any one could call a solution infantile or overly
engineered and not be sure which is correct.
   I can say that even a bad test will give you something to compare
with, but one needs to compare fully.. how will your application
respond to sudden server failure?, how will it respond to demand? make
a small scenario and basho_bench it, apply more criteria, see where
you get backed into a corner..
   The best ways to approach solving a problem seem bountiful until
you apply all the criteria required of the solution. Less criteria is
usually better, Riak has a pretty stringent criteria for a database
software, to scale and to remain highly available while making
relatively efficient use of resources..  Your designs should always
try to complement this. It is often hard to determine you've done that
(distributed computing probs) until you have a proof of concept and
start beating on it.
It seems in one of your use cases "game scores" this is relatively
immutable... Users made a score at a given time. Since they would not
go back and change this later.. TS could be potentially more efficient
if you designed around this. If you tried to design it in literally
any configuration you would need to test it and optimally make the
test available if you wanted to verify it will work for you over time,
or to confer with someone else.

Best,
Pedram


On Thu, Jun 16, 2016 at 12:28 PM, Gianluca Padovani  wrote:
> Hi Alexander thanks for your response.
>
> 2016-06-16 6:19 GMT+02:00 Alexander Sicular :
>>
>> My question to you is what is your
>> use case?
>>
>
> This is the problem, I don't know it clearly. There are some use cases very
> clear. For example I need to verify username and password on a big bunch of
> users, manage some data about users, and I think that RiakKV is perfect for
> this scenario, I clearly identify the user by username or email and check
> the password, update some data about it some earned points and some money. I
> think that riakKV is a perfect choice.
>
> Other scenario is to retrieve some data about the user something similar
> about your score or your games. This scenario is more difficult because I
> need to maintain a relation between the users and this objects, I'm
> evaluating to embed it in the user object but I don't think it's a good
> idea, because we have a lot of this object and probably I need to create a
> special keys or an intermediary objects to get all this data, divided by
> days ??!? In this scenario riakKV probably with Solar or 2i is yet good.
>
> Another scenario is something more statistical/analytical, and I don't know
> exactly but something like this: find the first 5 users with the best score
> divided for every region and for every city ... In this case, probably,
> RiakKV is not a good fit, (map/reduce?!?)
>
> Any suggestions? :-)
>
> thanks and bye
> Gianluca
>
> ___
> 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: How to cold (re)boot a cluster with already existing node data

[DeadZen]

I wasn't referring to a cluster replace. node name/reip change can be
done on all offline nodes before starting them.
They still have a cluster if you dont delete the ring data.
Having done that you actually deleted the cluster, (but not the data) when
all that occurred was an ip address change such that the node its looking
for in the dict. cant be found.

orddict,fetch,['riak@10.44.2.8'...
Youd want a reip of the old r...@10.xx to riak@10.44.2.8 iirc

then the node would boot as if nothing happened.

personally I think this state could be detected and a friendlier, I cant
find x have you recently transferred to a new node or ip? etc etc


On Monday, June 6, 2016, Sargun Dhillon  wrote:

> Two suggestions:
> 1. Use Riak-EE, and have two rings. When you do an update, copy over one
> ring to the other side after you do a "cold reboot"
> 2. Use the Riak Mesos Framework. Mesos is like K8s, but it has stateful
> storage primitives. (Link: https://github.com/basho-labs/riak-mesos)
>
> On Mon, Jun 6, 2016 at 10:37 AM, Jan-Philip Loos  > wrote:
>
>>
>>
>> On Mon, 6 Jun 2016 at 16:52 Alex Moore > > wrote:
>>
>>> Hi Jan,
>>>
>>> When you update the Kubernates nodes, do you have to do them all at once
>>> or can they be done in a rolling fashion (one after another)?
>>>
>>
>> Thnaks for your reply,
>>
>> sadly this is not possible. Kubernetes with GKE just tears all nodes
>> down, creating new nodes with new kubernets version and reschedule all
>> services on these nodes. So after an upgrade, all riak nodes are
>> stand-alone (when starting after deleting /var/lib/riak/ring)
>>
>> Greetings
>>
>> Jan
>>
>>
>>> If you can do them rolling-wise, you should be able to:
>>>
>>> For each node, one at a time:
>>> 1. Shut down Riak
>>> 2. Shutdown/restart/upgrade Kubernates
>>> 3. Start Riak
>>> 4. Use `riak-admin force-replace` to rename the old node name to the new
>>> node name
>>> 5. Repeat on remaining nodes.
>>>
>>> This is covered in "Renaming Multi-node clusters
>>> "
>>> doc.
>>>
>>> As for your current predicament,  have you created any new
>>> buckets/changed bucket props in the default namespace since you restarted?
>>> Or have you only done regular operations since?
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>> On Mon, Jun 6, 2016 at 5:25 AM Jan-Philip Loos >> > wrote:
>>>
 Hi,

 we are using riak in a kuberentes cluster (on GKE). Sometimes it's
 necessary to reboot the complete cluster to update the kubernetes-nodes.
 This results in a complete shutdown of the riak cluster and the riak-nodes
 are rescheduled with a new IP. So how can I handle this situation? How can
 I form a new riak cluster out of the old nodes with new names?

 The /var/lib/riak directory is persisted. I had to delete the
 /var/lib/riak/ring folder otherwise "riak start" crashed with this message
 (but saved the old ring state in a tar):

 {"Kernel pid
> terminated",application_controller,"{application_start_failure,riak_core,{{shutdown,{failed_to_start_child,riak_core_broadcast,{'EXIT',{function_clause,[{orddict,fetch,['
> riak@10.44.2.8 
> ',[]],[{file,\"orddict.erl\"},{line,72}]},{riak_core_broadcast,init_peers,1,[{file,\"src/riak_core_broadcast.erl\"},{line,616}]},{riak_core_broadcast,start_link,0,[{file,\"src/riak_core_broadcast.erl\"},{line,116}]},{supervisor,do_start_child,2,[{file,\"supervisor.erl\"},{line,310}]},{supervisor,start_children,3,[{file,\"supervisor.erl\"},{line,293}]},{supervisor,init_children,2,[{file,\"supervisor.erl\"},{line,259}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}],{riak_core_app,start,[normal,[]]}}}"}
> Crash dump was written to: /var/log/riak/erl_crash.dump
> Kernel pid terminated (application_controller)
> ({application_start_failure,riak_core,{{shutdown,{failed_to_start_child,riak_core_broadcast,{'EXIT',{function_clause,[{orddict,fetch,['
> riak@10.44.2.8 ',


 The I formed a new cluster via join & plan & commit.

 But now, I discovered a problems with incomplete and inconsistent
 partitions:

 *$ *curl -Ss "
 http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
 | jq '.[] | length'

 3064

 *$* curl -Ss "
 http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
 | jq '.[] | length'

 2987

 *$* curl -Ss "
 http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
 | jq '.[] 

Re: How to cold (re)boot a cluster with already existing node data

[DeadZen]

this might be helpful, an Omniti article.
https://omniti.com/seeds/migrating-riak-do-it-live

As to fixing this specific error. That iirc can be done doing a name change
in the ring to match your new node name.  renaming the node will make that
orddict lookup succeed.
Theres a supplied admin utility for that.


On Sunday, June 5, 2016, Jan-Philip Loos  wrote:

> Hi,
>
> we are using riak in a kuberentes cluster (on GKE). Sometimes it's
> necessary to reboot the complete cluster to update the kubernetes-nodes.
> This results in a complete shutdown of the riak cluster and the riak-nodes
> are rescheduled with a new IP. So how can I handle this situation? How can
> I form a new riak cluster out of the old nodes with new names?
>
> The /var/lib/riak directory is persisted. I had to delete the
> /var/lib/riak/ring folder otherwise "riak start" crashed with this message
> (but saved the old ring state in a tar):
>
> {"Kernel pid
>> terminated",application_controller,"{application_start_failure,riak_core,{{shutdown,{failed_to_start_child,riak_core_broadcast,{'EXIT',{function_clause,[{orddict,fetch,['
>> riak@10.44.2.8 
>> ',[]],[{file,\"orddict.erl\"},{line,72}]},{riak_core_broadcast,init_peers,1,[{file,\"src/riak_core_broadcast.erl\"},{line,616}]},{riak_core_broadcast,start_link,0,[{file,\"src/riak_core_broadcast.erl\"},{line,116}]},{supervisor,do_start_child,2,[{file,\"supervisor.erl\"},{line,310}]},{supervisor,start_children,3,[{file,\"supervisor.erl\"},{line,293}]},{supervisor,init_children,2,[{file,\"supervisor.erl\"},{line,259}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}],{riak_core_app,start,[normal,[]]}}}"}
>> Crash dump was written to: /var/log/riak/erl_crash.dump
>> Kernel pid terminated (application_controller)
>> ({application_start_failure,riak_core,{{shutdown,{failed_to_start_child,riak_core_broadcast,{'EXIT',{function_clause,[{orddict,fetch,['
>> riak@10.44.2.8 ',
>
>
> The I formed a new cluster via join & plan & commit.
>
> But now, I discovered a problems with incomplete and inconsistent
> partitions:
>
> *$ *curl -Ss "
> http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
> | jq '.[] | length'
>
> 3064
>
> *$* curl -Ss "
> http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
> | jq '.[] | length'
>
> 2987
>
> *$* curl -Ss "
> http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
> | jq '.[] | length'
>
> 705
>
> *$* curl -Ss "
> http://riak.default.svc.cluster.local:8098/buckets/users/keys?keys=true;
> | jq '.[] | length'
> 3064
>
> Is there a way to fix this? I guess this is caused by the missing old
> ring-state?
>
> Greetings
>
> Jan
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Riak not storing data in a round-robin manner across instances

[DeadZen]

np, number of nodes and ring size play a lot into that.
as does your r,w settings.
might be fun to create a visualization one day ;)

On Friday, May 27, 2016, Vikram Lalit <vikramla...@gmail.com> wrote:

> Ok got it thanks.
> On May 27, 2016 4:02 PM, "DeadZen" <dead...@deadzen.com
> <javascript:_e(%7B%7D,'cvml','dead...@deadzen.com');>> wrote:
>
>> reiterating my last email
>>
>> > theres no guarantee vnodes are assigned to unique servers..
>>
>> referencing the docs
>>
>> > Nodes *attempt* to claim their partitions at intervals around the ring
>> such that there is an even distribution amongst the member nodes and that
>> no node is responsible for more than one replica of a key.
>>
>>
>>
>> On Friday, May 27, 2016, Vikram Lalit <vikramla...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','vikramla...@gmail.com');>> wrote:
>>
>>> I have a Riak cluster (of 3 nodes, with 64 partitions and n_val = 3) but
>>> I find that for some objects, their hosting partitions / vnodes are not
>>> spread out across the 3 nodes. In some cases, 2 of them are on 1 node and
>>> the third is on a second node. That runs contrary to my understanding (link
>>> here: http://docs.basho.com/riak/kv/2.1.4/learn/concepts/clusters/)
>>> that the data is spread out across partitions in such a way that the
>>> partitions are on different servers. Is there something I'm missing here
>>> please in terms of how Riak works? Thanks...
>>>
>>>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Riak not storing data in a round-robin manner across instances

[DeadZen]

reiterating my last email

> theres no guarantee vnodes are assigned to unique servers..

referencing the docs

> Nodes *attempt* to claim their partitions at intervals around the ring
such that there is an even distribution amongst the member nodes and that
no node is responsible for more than one replica of a key.



On Friday, May 27, 2016, Vikram Lalit  wrote:

> I have a Riak cluster (of 3 nodes, with 64 partitions and n_val = 3) but I
> find that for some objects, their hosting partitions / vnodes are not
> spread out across the 3 nodes. In some cases, 2 of them are on 1 node and
> the third is on a second node. That runs contrary to my understanding (link
> here: http://docs.basho.com/riak/kv/2.1.4/learn/concepts/clusters/) that
> the data is spread out across partitions in such a way that the partitions
> are on different servers. Is there something I'm missing here please in
> terms of how Riak works? Thanks...
>
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Riak Recap, May 20th, 2016

[DeadZen]

whats the problem currently?
 something not working on freebsd?

On Thursday, May 26, 2016, Seema Jethani > wrote:

> Hello All,
> Basho is no longer directly supporting FreeBSD due to low levels of
> adoption amongst our commercial customers, but we are looking for members
> of the community to help tackle FreeBSD support.
> We appreciate your help!
>
> Regards
> Seema
>
> --
> Seema Jethani
> Director of Product Management, Basho 
> 4083455739 | @seemaj 
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Riak Cluster Behavior - Clarification

[DeadZen]

Not to jump to conclusions, but this sounds like a quorum issue.
Such as your writes are not going to all three servers, but only to one or two.
Handoffs would occur when nodes went down unexpectedly, it doesn't
ever attempt to fetch unwritten data, it fetches data from other
servers which were still up at the point the server went down..
There are some configuration values you could experiment with, that
will ok a write only as long as its gone to a durable storage count..
But keep in mind theres no guarantee vnodes are assigned to unique
servers..


On Tue, May 24, 2016 at 4:08 PM, Vikram Lalit  wrote:
> It's returning no object at all for the relevant key. That too is random -
> every few calls it returns but then it doesn't.
>
> On May 24, 2016 4:06 PM, "Sargun Dhillon"  wrote:
>>
>> What do you mean it's not returning? It's returning stale data? Or
>> it's erroring?
>>
>> On Tue, May 24, 2016 at 7:34 AM, Vikram Lalit 
>> wrote:
>> > Hi - I'd appreciate if someone can opine on the below behavior of Riak
>> > that
>> > I am observing... is that expected, or something wrong in my set-up /
>> > understanding?
>> >
>> > To summarize, I have a 3-node Riak cluster (separate EC2 AWS instances)
>> > with
>> > a separate chat server connecting to them. When I write data on the Riak
>> > nodes, the process is successful and I can read all data correctly.
>> > However,
>> > as part of my testing, if I deliberately bring down one node (and then
>> > remove it from the cluster using riak-admin cluster force-remove / plan
>> > /
>> > commit), the client API is not able to fetch all the written data. In
>> > fact,
>> > there is an alternation of success and failure which happens rather
>> > randomly.
>> >
>> > My initial suspicion was that it would be happening only during the time
>> > the
>> > rebalancing is occurring (i.e. riak-admin ring-status is not fully
>> > settled)
>> > but I've seen this sporadic behavior post the same too.
>> >
>> > Does this have to do with the n and r values for the cluster and given
>> > that
>> > 1 node is down, the cluster does not succeed in returning results
>> > reliably?
>> > Also, does this mean that during the time a cluster is being rebalanced
>> > (even incl. addition of new nodes), the results could be arbitrary -
>> > that
>> > doesn't sound correct to me?
>> >
>> > Appreciate if someone can throw some light here? Also, the HTTP API
>> > calls to
>> > retrieve and set the n / r / w values for a specific bucket - couldn't
>> > locate the same!
>> >
>> > Thanks much!
>> > Vikram
>> >
>> >
>> > ___
>> > 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
>

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Riak Recap, May 20th, 2016

[DeadZen]

Any reason for the FreeBSD support drop?
Run into issues?

On Friday, May 20, 2016, Alexander Sicular  wrote:

> Hello All,
>
> Just in time for the weekend we bring you a rundown of announcements,
> jobs, some code and, of course, the mailing list review.
>
> As always, we want to hear from you. If you’re working on or speaking
> about something Riak related and would like to be highlighted - send me a
> note! Let me know what you’re up to and I’ll get your talk or blog post in
> the next Riak Recap.
>
> ## Announcements
>
>
>-
>
>Two client library updates this week, PHP and .NET. Check em out:
>-
>
>   Riak PHP Client v 3.1.0 adds access to Riak TS via HTTP [0]
>   -
>
>   Riak .NET Client v 2.3.0 brings Riak TS and external load balancing
>   support [1]
>   -
>
>A Riak TS AMI for AWS is now available [2].
>
>
>
> ## Community Code and Walkthroughs
>
>
>-
>
>Craig Vitter put some code out accompanying his talk last week in NYC
>on Riak TS. The code walks through using Riak TS with python and jupyter
>[3].
>-
>
>Seema Jethani also drops some code with a talk she gave this week at
>Data By the Bay in San Francisco on working with time series data from the
>London Air Quality Network in Riak TS and other projects [4].
>-
>
>Stephen Etheridge shows us how to get started with Spark and Riak TS
>[5].
>-
>
>Susan Lee introduces us to Riak TS using Stephens code [6].
>
>
>
> ##Community Events
>
>
>-
>
>Basho Engineer Jason Voegele, @jvoegele, will be giving a talk at
>LambdaConf in Boulder, CO entitled “Dialyzer: Optimistic Type Checking for
>Erlang and Elixir” [7].
>
>
>
> ## Jobs at Basho
>
> Interested in working on distributed computing related problems or helping
> our community with theirs? Perhaps these open positions at Basho may be of
> interest:
>
>
>-
>
>Client Services Engineer (USA) [8].
>-
>
>Developer Advocate (London and US) [9].
>
>
> Basho is remote friendly!
>
>
> ## Recently Answered
>
>
>-
>
>Alex gets help modifying the default Solr schema [10].
>-
>
>Luke goes above and beyond helping Sanket debug his AWS environment in
>order to get pre-commit hooks working [11]. If you’re looking to do
>something similar, instructions are here [12].
>-
>
>Alex and I have a conversation about Solr schema design. To store or
>not to store. [13].
>-
>
>Luke confirms Basho is working on security and drop/truncate table
>features in upcoming releases [14].
>-
>
>Daniel helps David grok deleting an object in Riak [15]. Welcome
>aboard, David!
>-
>
>Kaz helps a different David by pointing out two key Riak KV
>configuration options when setting up KV for Riak CS [16].
>-
>
>Vitaly helps Alex with Solr indexing [17] and Drew highlights specific
>sections of the default Solr schema shipped with Riak KV [18].
>-
>
>Fred points out to Alex that although you can query Solr directly,
>there are considerations [19]. John queries Solr directly after caching a
>copy of the cluster plan every so often [20].
>-
>
>Vitaly shows Alex how to configure Solr for case insensitive indexing
>[21].
>-
>
>Magnus confirms that Basho is working on making Riak compatible with
>Erlang OTP 18 [22] and highlights a github issue and pull request that help
>Humberto with his specific compilation issue on OSX.
>-
>
>Luke confirms to one Outback Dingo that Riak TS is not supported on
>FreeBSD and support for Riak KV on FreeBSD will be discontinued [23].
>-
>
>Serena is seeking out a Debian Jesse package. Brett assures us a
>package is on the way [24].
>
>
>
> ## Open Discussions
>
>
>-
>
>Vladimir asks the list for help with the following warning “perflists
>do not satisfy the n_val” [25].
>-
>
>Alex is looking for advice regarding whether or not Riak TS would be
>better suited in certain use cases over Riak KV for his social network
>project [26].
>-
>
>Michael is looking for some guidance on properly sizing a Riak S2
>cluster [27].
>-
>
>Psterk is looking for help on using hadoops’s distcpy to copy files
>from Riak S2 to hadoop [28][29].
>-
>
>The conversation around Riak DT [30] continues with Sargun offering to
>contribute some enhancements [31]. In case you’re wondering, yes,
>contributions will be highlighted.
>-
>
>Johnny is looking for help working with credentials in Riak S2 [32].
>-
>
>A number of folks contribute to a great thread helping Alex on his
>question about write performance when writing sequential alpha-numeric keys
>[33]. There is a sidebar on CRDT’s vs write_once buckets in there as well
>[34].
>
>
>
> Have a great weekend,
>
> -Alexander Sicular
>
> Solution Architect, Basho
>
> @siculars
>
> [0] 

Re: Riak DT refresh

[DeadZen]

Been looking at lasp a little seems quite interesting!.

On Saturday, May 7, 2016, Russell Brown <russell.br...@me.com> wrote:

> In erlang? Might save myself the trouble and wait if so.
>
> On 7 May 2016, at 13:12, Christopher Meiklejohn <
> christopher.meiklej...@gmail.com <javascript:;>> wrote:
>
> > We are also using Riak DT as a base.  However, we are doing a greenfield
> implementation of the new delta work in Lasp and hope to have an
> open-source library of these implementations available soon.
> >
> > - Christopher
> >
> > On Saturday, May 7, 2016, DeadZen <dead...@deadzen.com <javascript:;>>
> wrote:
> > +1
> >
> > On Fri, May 6, 2016 at 8:17 PM, Sargun Dhillon <sar...@sargun.me
> <javascript:;>> wrote:
> > > We're using riak_dt in anger in our product. We are already using it
> > > with rebar3, and Erlang 18.3 through some super messy patches.
> > >
> > > I would love to see a register that takes the logical clock, and
> > > timestamp for resolution, rather than just a straightup timestamp. My
> > > biggest ask though is delta-CRDTs. Delta-CRDTs with a decent
> > > anti-entropy algorithm would allow our system to scale from 1000s of
> > > keys to 100ks of keys.
> > >
> > > Nonetheless, Riak_dt is an awesome library, and we're probably
> > > planning on contributing back to it soonish, especially if any of the
> > > other comments on this thread are things we need, and Basho doesn't.
> > >
> > > On Thu, Apr 28, 2016 at 12:55 AM, Russell Brown <russell.br...@me.com
> <javascript:;>> wrote:
> > >> Hi,
> > >> Riak DT[1] is in need of some love. I know that some of you on this
> list (Sargun, are you here? Heinz?) have expressed opinions on the work
> that needs doing. Here is my short list, I would love to hear opinions on
> priority, and any additions to this list:
> > >>
> > >> 1. merger smaller map branch
> > >> 2. deltas
> > >> 3. new data types (we have a range register and some and
> Multi-Value-Register to add, any more?)
> > >> 4. Internal state as records or maps (but not these messy tuples)
> > >> 5. update to rebar3
> > >> 6. update to latest erlang
> > >>
> > >> I’m pretty sure there is plenty more. Would greatly appreciate your
> feedback.
> > >>
> > >> Many thanks
> > >>
> > >> Russell
> > >>
> > >> [1] https://github.com/basho/riak_dt/
> > >> ___
> > >> riak-users mailing list
> > >> riak-users@lists.basho.com <javascript:;>
> > >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> > >
> > > ___
> > > riak-users mailing list
> > > riak-users@lists.basho.com <javascript:;>
> > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >
> > ___
> > riak-users mailing list
> > riak-users@lists.basho.com <javascript:;>
> > 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: Riak DT refresh

[DeadZen]

+1

On Fri, May 6, 2016 at 8:17 PM, Sargun Dhillon  wrote:
> We're using riak_dt in anger in our product. We are already using it
> with rebar3, and Erlang 18.3 through some super messy patches.
>
> I would love to see a register that takes the logical clock, and
> timestamp for resolution, rather than just a straightup timestamp. My
> biggest ask though is delta-CRDTs. Delta-CRDTs with a decent
> anti-entropy algorithm would allow our system to scale from 1000s of
> keys to 100ks of keys.
>
> Nonetheless, Riak_dt is an awesome library, and we're probably
> planning on contributing back to it soonish, especially if any of the
> other comments on this thread are things we need, and Basho doesn't.
>
> On Thu, Apr 28, 2016 at 12:55 AM, Russell Brown  wrote:
>> Hi,
>> Riak DT[1] is in need of some love. I know that some of you on this list 
>> (Sargun, are you here? Heinz?) have expressed opinions on the work that 
>> needs doing. Here is my short list, I would love to hear opinions on 
>> priority, and any additions to this list:
>>
>> 1. merger smaller map branch
>> 2. deltas
>> 3. new data types (we have a range register and some and 
>> Multi-Value-Register to add, any more?)
>> 4. Internal state as records or maps (but not these messy tuples)
>> 5. update to rebar3
>> 6. update to latest erlang
>>
>> I’m pretty sure there is plenty more. Would greatly appreciate your feedback.
>>
>> Many thanks
>>
>> Russell
>>
>> [1] https://github.com/basho/riak_dt/
>> ___
>> 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

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: [ANN] Riak 2.0pre11

[DeadZen]

w00t

On Sat, Jan 18, 2014 at 3:27 PM, Luc Perkins lperk...@basho.com wrote:
 Dear Riak community,

 We're excited to bring you our first public release of a 2.0 preview since
 the tech preview that we unleashed at RICON West.

 The list of changes is too long to trivially enumerate, as effectively all
 of the new features (and some older ones) have been significantly improved,
 but I'll throw out a few highlights:

 * HTTP API for CRDTs
 * CRDT support for Riak Search (codename Yokozuna)
 * The schemas for riak.conf (cuttlefish) are frozen
 * Reduced sibling creation, inspired by the dotted versions vectors research
 from Preguiça, Baquero, et al[1]
 * Many AAE improvements
 * Solr 4.6.0 support in Riak Search
 * You can now use AAE to migrate from legacy Riak search to the new Riak
 Search

 You find the links of magical packed goodness on docs.basho.com[2].
 Unfortunately, documentation is still under active development, so please
 feel free to ask questions on the mailing list.

 [1] http://arxiv.org/abs/1011.5808
 [2] http://docs.basho.com/riak/2.0.0pre11/downloads

 -LP

 ___
 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