ExplicitLAC consolidation

[Enrico Olivelli <eo...@gmail.com>]

Hi Bookkeepers,
I am trying to draw the best roadmap with the goal of consolidating
ExplicitLAC feature.
Currently I have two big topics:
- on the reader side I would like enable new API users to leverage
ExplicitLAC, transparently (no new configuration, now readflags, no
explicit API calls)
- on the writer side make ExplicitLAC work better with DEFERRED_SYNC (like
having a background force() together with the sending of ExplicitLAC)

Currently I want to spend time mostly on the reader side, because it will
enable new clients to use ExplicitLAC.

My current (new) idea is to add a new flag on readEntry() RPC with which
the client asks for the ExplicitLAC together with the entry.

With this change we can support backward compatibility easily.
New clients will add that flag and they will be able to read the new
optional ExplicitLAC field.
Old bookies will ignore the flag.
Old clients won't ask for ExplicitLAC.

If there is no ExplicitLAC this new feature won't add costs on the wire.

After this discussion on the ML I will post a BP, if we agree that this
approach makes sense.

I have started to draft a prototype yet, I would like to hear your opinion
(as usual I have very limited time)

Regards
Enrico

Re: ExplicitLAC consolidation

[Enrico Olivelli <eo...@gmail.com>]

Il giorno lun 11 feb 2019 alle ore 06:03 Sijie Guo
<gu...@gmail.com> ha scritto:
>
> On Mon, Feb 11, 2019 at 6:09 AM Venkateswara Rao Jujjuri <ju...@gmail.com>
> wrote:
>
> > Thanks for bringing this up. To start with, can we put all forms on LAC in
> > a doc? i.e we have more than one way to read and write LAC.
> > 1. What are the ways to send LAC to Bookies?
> > 2. What are the ways bookies store the LAC?
> > 3. What are the ways client can learn about LAC
> > and the interfaces and configuration parameters around it, and what are the
> > usecases of these?
> >
>
> +1 I would also like to see a doc (via BP on google doc) for this as well.
>
> >
> > I may be asking for more work here, but I think that way we can make more
> > informed decision. What do you think Enrico?
> > If you lead this, I will be more than happy to fill-in parts of this doc,
> > and even review them.

Sure I am starting right now the discussion and I am going to lead
these improvements.

I will create a draft soon on Google Docs.

Enrico

> >
> > Thanks,
> > JV
> >
> > On Sun, Feb 10, 2019 at 1:23 AM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > Hi Bookkeepers,
> > > I am trying to draw the best roadmap with the goal of consolidating
> > > ExplicitLAC feature.
> > > Currently I have two big topics:
> > > - on the reader side I would like enable new API users to leverage
> > > ExplicitLAC, transparently (no new configuration, now readflags, no
> > > explicit API calls)
> > > - on the writer side make ExplicitLAC work better with DEFERRED_SYNC
> > (like
> > > having a background force() together with the sending of ExplicitLAC)
> > >
> > > Currently I want to spend time mostly on the reader side, because it will
> > > enable new clients to use ExplicitLAC.
> > >
> > > My current (new) idea is to add a new flag on readEntry() RPC with which
> > > the client asks for the ExplicitLAC together with the entry.
> > >
> > > With this change we can support backward compatibility easily.
> > > New clients will add that flag and they will be able to read the new
> > > optional ExplicitLAC field.
> > > Old bookies will ignore the flag.
> > > Old clients won't ask for ExplicitLAC.
> > >
> > > If there is no ExplicitLAC this new feature won't add costs on the wire.
> > >
> > > After this discussion on the ML I will post a BP, if we agree that this
> > > approach makes sense.
> > >
> > > I have started to draft a prototype yet, I would like to hear your
> > opinion
> > > (as usual I have very limited time)
> > >
> > > Regards
> > > Enrico
> > >
> >
> >
> > --
> > Jvrao
> > ---
> > First they ignore you, then they laugh at you, then they fight you, then
> > you win. - Mahatma Gandhi
> >

Re: ExplicitLAC consolidation

[Sijie Guo <gu...@gmail.com>]

On Mon, Feb 11, 2019 at 6:09 AM Venkateswara Rao Jujjuri <ju...@gmail.com>
wrote:

> Thanks for bringing this up. To start with, can we put all forms on LAC in
> a doc? i.e we have more than one way to read and write LAC.
> 1. What are the ways to send LAC to Bookies?
> 2. What are the ways bookies store the LAC?
> 3. What are the ways client can learn about LAC
> and the interfaces and configuration parameters around it, and what are the
> usecases of these?
>

+1 I would also like to see a doc (via BP on google doc) for this as well.

>
> I may be asking for more work here, but I think that way we can make more
> informed decision. What do you think Enrico?
> If you lead this, I will be more than happy to fill-in parts of this doc,
> and even review them.
>
> Thanks,
> JV
>
> On Sun, Feb 10, 2019 at 1:23 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Hi Bookkeepers,
> > I am trying to draw the best roadmap with the goal of consolidating
> > ExplicitLAC feature.
> > Currently I have two big topics:
> > - on the reader side I would like enable new API users to leverage
> > ExplicitLAC, transparently (no new configuration, now readflags, no
> > explicit API calls)
> > - on the writer side make ExplicitLAC work better with DEFERRED_SYNC
> (like
> > having a background force() together with the sending of ExplicitLAC)
> >
> > Currently I want to spend time mostly on the reader side, because it will
> > enable new clients to use ExplicitLAC.
> >
> > My current (new) idea is to add a new flag on readEntry() RPC with which
> > the client asks for the ExplicitLAC together with the entry.
> >
> > With this change we can support backward compatibility easily.
> > New clients will add that flag and they will be able to read the new
> > optional ExplicitLAC field.
> > Old bookies will ignore the flag.
> > Old clients won't ask for ExplicitLAC.
> >
> > If there is no ExplicitLAC this new feature won't add costs on the wire.
> >
> > After this discussion on the ML I will post a BP, if we agree that this
> > approach makes sense.
> >
> > I have started to draft a prototype yet, I would like to hear your
> opinion
> > (as usual I have very limited time)
> >
> > Regards
> > Enrico
> >
>
>
> --
> Jvrao
> ---
> First they ignore you, then they laugh at you, then they fight you, then
> you win. - Mahatma Gandhi
>

Re: ExplicitLAC consolidation

[Venkateswara Rao Jujjuri <ju...@gmail.com>]

Thanks for bringing this up. To start with, can we put all forms on LAC in
a doc? i.e we have more than one way to read and write LAC.
1. What are the ways to send LAC to Bookies?
2. What are the ways bookies store the LAC?
3. What are the ways client can learn about LAC
and the interfaces and configuration parameters around it, and what are the
usecases of these?

I may be asking for more work here, but I think that way we can make more
informed decision. What do you think Enrico?
If you lead this, I will be more than happy to fill-in parts of this doc,
and even review them.

Thanks,
JV

On Sun, Feb 10, 2019 at 1:23 AM Enrico Olivelli <eo...@gmail.com> wrote:

> Hi Bookkeepers,
> I am trying to draw the best roadmap with the goal of consolidating
> ExplicitLAC feature.
> Currently I have two big topics:
> - on the reader side I would like enable new API users to leverage
> ExplicitLAC, transparently (no new configuration, now readflags, no
> explicit API calls)
> - on the writer side make ExplicitLAC work better with DEFERRED_SYNC (like
> having a background force() together with the sending of ExplicitLAC)
>
> Currently I want to spend time mostly on the reader side, because it will
> enable new clients to use ExplicitLAC.
>
> My current (new) idea is to add a new flag on readEntry() RPC with which
> the client asks for the ExplicitLAC together with the entry.
>
> With this change we can support backward compatibility easily.
> New clients will add that flag and they will be able to read the new
> optional ExplicitLAC field.
> Old bookies will ignore the flag.
> Old clients won't ask for ExplicitLAC.
>
> If there is no ExplicitLAC this new feature won't add costs on the wire.
>
> After this discussion on the ML I will post a BP, if we agree that this
> approach makes sense.
>
> I have started to draft a prototype yet, I would like to hear your opinion
> (as usual I have very limited time)
>
> Regards
> Enrico
>


-- 
Jvrao
---
First they ignore you, then they laugh at you, then they fight you, then
you win. - Mahatma Gandhi