Re: [DISCUSS] CEP-8 Drivers Donation

[Alexandre Dutra]

Hi Alex and Jeremy,

We've been thinking of the driver codebase on a repository level in the
CEP, which is why we do not mention any specific branch. To clarify, our
intention is to donate the entire repository, including all existing
commits, branches and tags. So don't worry: the Java driver 3.x branch
would naturally be part of the donation. I will include a sentence in the
CEP to make this statement explicit.

Thanks,
Alex

On Tue, Aug 4, 2020 at 8:30 PM Jeremy Chapman 
wrote:

> +1 on both starting with just the Java driver first and contributing all
> 3.x and 4.x branches. Some of our long-running apps may continue using 3.x
> for quite a while simply due to the extra effort due to their
> deep-maintenance lifestyle.
>
> -Jeremy
>
> On Tue, Aug 4, 2020 at 4:26 AM Oleksandr Petrov <
> oleksandr.pet...@gmail.com>
> wrote:
>
> > I've tried to find this information in the document above, but couldn't
> > find an explicit mention of it, possibly because it's implied. If we take
> > java-driver as an example, is this CEP proposing to contribute all
> branches
> > (3.x and 4.x) or only the latest one?
> >
> > Thank you,
> > -- Alex
> >
> > On Wed, Jul 29, 2020 at 12:16 PM Alexandre Dutra <
> > alexandre.du...@datastax.com> wrote:
> >
> > > Hi Dinesh,
> > >
> > > While we think that maintaining the drivers together as a long-term
> goal
> > > would be beneficial as it would allow the drivers to evolve together
> and
> > > adopt similar design decisions, we also understand that donating 7
> > drivers
> > > at once may put the whole operation at risk, as some folks here already
> > > pointed out.
> > >
> > > The current CEP text actually advocates for a phased approach (see
> > > "Approach" section):
> > >
> > > [...] the donation process will be iterative, and will start with only
> > the
> > > > Java driver in a first phase; then, in a second phase, it will be
> > > extended
> > > > to the remaining drivers.
> > > > Once the Java driver is transferred, and before the others are
> > > > transferred, we will revise the methodology described in this CEP,
> and
> > if
> > > > necessary, revise its parameters and adjust them accordingly. A
> second
> > > CEP
> > > > may be required if the changes to the methodology are found to be
> > > > substantial.
> > > >
> > >
> > > What do you think of this idea, does it sound reasonable ?
> > >
> > > Thanks,
> > >
> > > Alex
> > >
> > > On Mon, Jul 27, 2020 at 11:53 PM Dinesh Joshi 
> wrote:
> > >
> > > > Alexandre,
> > > >
> > > > I gave the document a quick read and TL;DR seems to be that we'd like
> > to:
> > > >
> > > > 1. Bring in all drivers
> > > > 2. They're part of the C* project
> > > >
> > > > If so, I would prefer if we add the Java driver first to the project.
> > > > Based on that experience we can move forward with other drivers.
> > > However, I
> > > > am open to the idea of adding all the drivers to the project.
> > > >
> > > > Please correct me if I misunderstood something.
> > > >
> > > > Thanks,
> > > >
> > > > Dinesh
> > > >
> > > > > On Jul 26, 2020, at 8:41 PM, Nate McCall 
> wrote:
> > > > >
> > > > > This is fantastic, Alexandre, thanks for putting this together!
> > > > >
> > > > > I put an initial set of comments/concerns on there and will loop
> back
> > > > later
> > > > > this week after other folks have  a go.
> > > > >
> > > > > Cheers,
> > > > > -Nate
> > > > >
> > > > > On Sat, Jul 25, 2020 at 7:35 AM Alexandre Dutra <
> > > > > alexandre.du...@datastax.com> wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> As per the CEP process guidelines, I'm starting a formal DISCUSS
> > > > >> thread to resume the conversation
> > > > >> started here[1].
> > > > >>
> > > > >> On behalf of the developers who maintain the DataStax drivers, I
> > > > >> confirm that we are offering to
> > > > >> donate to the Apache Software Foundation all seven DataStax-funded
> > > > >> drivers, and are therefore
> > > > >> opening this CEP[2] to discussion.
> > > > >>
> > > > >> In the CEP document linked above, we tried our best to address all
> > the
> > > > >> issues that we anticipate
> > > > >> going forward with this endeavor, but the task is big: your
> > > > >> suggestions, remarks and comments are
> > > > >> most welcome.
> > > > >>
> > > > >> As stated previously, we understand that we're all primarily
> focused
> > > > >> on the C* 4.0 release
> > > > >> currently; therefore we don't mind deferring any concrete progress
> > on
> > > > >> this until after C* 4.0 is
> > > > >> out.
> > > > >>
> > > > >> However, as you can judge from the CEP draft document, the
> donation
> > is
> > > > >> likely to have many
> > > > >> implications on sensitive areas, e.g. on project governance; which
> > is
> > > > >> why we think best to open the
> > > > >> discussion as early as possible, so that we all have enough time
> to
> > > > >> determine what we think best
> > > > >> suits the project going forward.
> > > > >>
> > > > >> Kind regards,
> > > > >>
> > > > >> Al

Re: [DISCUSS] Updating the C* website design

[Michael Semb Wever]

> See that here:
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> 
> This outline is not complete, just my initial scribblings. Certainly
> collaboration would be welcome.


This is awesome Lorina. It would also be great to see all non-versioned docs 
moved out of the cassandra repository and into the cassandra-website repository 
(where they become easier to update).

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

The one issue I see with your suggestion about versioned/non-versioned docs
is that the cassandra/doc repo will have asciidoc files, and currently, all
the items in the cassandra-website repo are in markdown. There are possible
solutions (use antora for the website, put the non-versioned docs in their
own repo which antora can use for building, for example), but that needs
exploration.

Lorina Poland




On Wed, Aug 5, 2020 at 12:06 PM Michael Semb Wever  wrote:

>
>
> > See that here:
> >
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> >
> > This outline is not complete, just my initial scribblings. Certainly
> > collaboration would be welcome.
>
>
> This is awesome Lorina. It would also be great to see all non-versioned
> docs moved out of the cassandra repository and into the cassandra-website
> repository (where they become easier to update).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CEP-8 Drivers Donation

[Jeremy Chapman]

Alex,

That's awesome! Thanks for the clarification.

-Jeremy

On Wed, Aug 5, 2020 at 1:18 AM Alexandre Dutra 
wrote:

> Hi Alex and Jeremy,
>
> We've been thinking of the driver codebase on a repository level in the
> CEP, which is why we do not mention any specific branch. To clarify, our
> intention is to donate the entire repository, including all existing
> commits, branches and tags. So don't worry: the Java driver 3.x branch
> would naturally be part of the donation. I will include a sentence in the
> CEP to make this statement explicit.
>
> Thanks,
> Alex
>
> On Tue, Aug 4, 2020 at 8:30 PM Jeremy Chapman  >
> wrote:
>
> > +1 on both starting with just the Java driver first and contributing all
> > 3.x and 4.x branches. Some of our long-running apps may continue using
> 3.x
> > for quite a while simply due to the extra effort due to their
> > deep-maintenance lifestyle.
> >
> > -Jeremy
> >
> > On Tue, Aug 4, 2020 at 4:26 AM Oleksandr Petrov <
> > oleksandr.pet...@gmail.com>
> > wrote:
> >
> > > I've tried to find this information in the document above, but couldn't
> > > find an explicit mention of it, possibly because it's implied. If we
> take
> > > java-driver as an example, is this CEP proposing to contribute all
> > branches
> > > (3.x and 4.x) or only the latest one?
> > >
> > > Thank you,
> > > -- Alex
> > >
> > > On Wed, Jul 29, 2020 at 12:16 PM Alexandre Dutra <
> > > alexandre.du...@datastax.com> wrote:
> > >
> > > > Hi Dinesh,
> > > >
> > > > While we think that maintaining the drivers together as a long-term
> > goal
> > > > would be beneficial as it would allow the drivers to evolve together
> > and
> > > > adopt similar design decisions, we also understand that donating 7
> > > drivers
> > > > at once may put the whole operation at risk, as some folks here
> already
> > > > pointed out.
> > > >
> > > > The current CEP text actually advocates for a phased approach (see
> > > > "Approach" section):
> > > >
> > > > [...] the donation process will be iterative, and will start with
> only
> > > the
> > > > > Java driver in a first phase; then, in a second phase, it will be
> > > > extended
> > > > > to the remaining drivers.
> > > > > Once the Java driver is transferred, and before the others are
> > > > > transferred, we will revise the methodology described in this CEP,
> > and
> > > if
> > > > > necessary, revise its parameters and adjust them accordingly. A
> > second
> > > > CEP
> > > > > may be required if the changes to the methodology are found to be
> > > > > substantial.
> > > > >
> > > >
> > > > What do you think of this idea, does it sound reasonable ?
> > > >
> > > > Thanks,
> > > >
> > > > Alex
> > > >
> > > > On Mon, Jul 27, 2020 at 11:53 PM Dinesh Joshi 
> > wrote:
> > > >
> > > > > Alexandre,
> > > > >
> > > > > I gave the document a quick read and TL;DR seems to be that we'd
> like
> > > to:
> > > > >
> > > > > 1. Bring in all drivers
> > > > > 2. They're part of the C* project
> > > > >
> > > > > If so, I would prefer if we add the Java driver first to the
> project.
> > > > > Based on that experience we can move forward with other drivers.
> > > > However, I
> > > > > am open to the idea of adding all the drivers to the project.
> > > > >
> > > > > Please correct me if I misunderstood something.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Dinesh
> > > > >
> > > > > > On Jul 26, 2020, at 8:41 PM, Nate McCall 
> > wrote:
> > > > > >
> > > > > > This is fantastic, Alexandre, thanks for putting this together!
> > > > > >
> > > > > > I put an initial set of comments/concerns on there and will loop
> > back
> > > > > later
> > > > > > this week after other folks have  a go.
> > > > > >
> > > > > > Cheers,
> > > > > > -Nate
> > > > > >
> > > > > > On Sat, Jul 25, 2020 at 7:35 AM Alexandre Dutra <
> > > > > > alexandre.du...@datastax.com> wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> As per the CEP process guidelines, I'm starting a formal DISCUSS
> > > > > >> thread to resume the conversation
> > > > > >> started here[1].
> > > > > >>
> > > > > >> On behalf of the developers who maintain the DataStax drivers, I
> > > > > >> confirm that we are offering to
> > > > > >> donate to the Apache Software Foundation all seven
> DataStax-funded
> > > > > >> drivers, and are therefore
> > > > > >> opening this CEP[2] to discussion.
> > > > > >>
> > > > > >> In the CEP document linked above, we tried our best to address
> all
> > > the
> > > > > >> issues that we anticipate
> > > > > >> going forward with this endeavor, but the task is big: your
> > > > > >> suggestions, remarks and comments are
> > > > > >> most welcome.
> > > > > >>
> > > > > >> As stated previously, we understand that we're all primarily
> > focused
> > > > > >> on the C* 4.0 release
> > > > > >> currently; therefore we don't mind deferring any concrete
> progress
> > > on
> > > > > >> this until after C* 4.0 is
> > > > > >> out.
> > > > > >>
> > > > > >> However, as you can judge from the CEP draft

Cassandra Kubernetes SIG - status update

[John Sanda]

I want to provide folks with a brief summary of what I have been up to
prior to the next SIG meeting. As mentioned in a previous email, I have
created https://github.com/jsanda/cassandra-operator and started adding
code.

Goals or objectives include:

   - Increase collaboration
   - Spur more in-depth discussion
   - Ramp up a project that can eventually be considered for adoption
   within ASF, presumably as a subproject of Cassandra

Objectives do not include:

   - Reinvent work that has already been done in existing operator projects
   - Accumulating a lot of tech debt

Details:
I am using operator-sdk v0.19.0 which has a bunch of changes from the
version I was previously using, namely it uses the same scaffolding and
project structure as Kubebuilder. This includes extensive use of kustomize.
The test framework has been removed from operator-sdk.

I have literally (and shamelessly) been copying/pasting bits of code from
both cass-operator and from casskop. So far the controller generates a
couple headless services and a StatefulSet. I currently have some things
hard coded, like the number of replicas in the StatefulSet, as I am just
trying to sanity check things.

I started off using the "default" Docker Hub Cassandra image. I needed to
make some changes to C* configs, so I added initial support for
cass-config-builder . I
had to extend the Cassandra image in order to be able to copy config files
into the CASSANDRA_CONF dir.

cass-config-builder configures Cassandra to
use org.apache.cassandra.locator.K8SeedProvider. This class however is
defined in management-api-for-apache-cassandra
, i.e.,
the DataStax management sidecar. I am not using the management sidecar yet,
but updated my C* image to include the agent JAR which contains the
K8SeedProvider class. I am still trying to iron out some of the wrinkles.

There are no integration/e2e tests yet. I don't want to get too much
further along without having some decent e2e test coverage.

That's all for now.

Thanks

- John