Re: Monthly community blog - thoughts?

[Horia Mocioi]

Sounds good.

How should we send suggestions? Via email or we can do it ourselves?

Regards,
Horia

On Thu, Oct 15, 2020 at 11:58 PM Erick Ramirez 
wrote:

> What a great idea! This is a good signal on how active the community is.
>
> I'm happy to help with proof-reading/reviews.
>
> P.S. The section on Harry contains HTML code. :)
>

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[franck.dehay]

Hi all, sorry for the delay we were busy releasing V1 of CassKop which happened 
this week:
https://github.com/Orange-OpenSource/casskop

Now we would like to open the discussions about feature merging and I would 
like to follow Joshua’s proposition: open issues on cass-operator.

As I said, we discuss first and if we find a way forward then we do it!

We will open the issues next week and move forward.

We can discuss them during the next SIG calls from thursday

Franck


On 6 Oct 2020, at 08:02, Ben Bromhead 
mailto:b...@instaclustr.com>> wrote:

Thanks Frank and Christopher.

Sounds like we have a good path to consolidate around!

On Sat, Oct 3, 2020 at 11:12 AM Joshua McKenzie 
mailto:jmcken...@apache.org>>
wrote:

how to best merge Casskop's features in Cass-operator.

What if we create issues on the gh repo here
https://github.com/datastax/cass-operator/issues, create a milestone out
of
that, and have engineers rally on it to get things merged? We have a few
engineers focused on k8s ecosystem for Cassandra from the DataStax side
who'd be happy to collaborate with you folks to get these things in.


On Fri, Oct 02, 2020 at 11:34 AM, 
mailto:franck.de...@orange.com>> wrote:

An update on Orange's point of view following the recent emails:

If we were a newly interested party in running C* in K8s, we would use
Cass-operator as it comes from Datastax.

The logic would then be that the community embraces it and thanks
Datastax
for offering it!

So, on Orange side, we propose to discuss with Datastax how to best merge
Casskop's features in Cass-operator. These features are:
- nodes labelling to map any internal architecture (including network
specific labels to muti-dc setup)
- volumes & sidecars management (possibly linked to PodTemplateSpec)
- backup & restore (we ruled out velero and can share why we went with
Instaclustr but Medusa could work too)
- kubectl plugin integration (quite useful on the ops side without an
admin UI)
- multiCassKop evolution to drive multiple cass-operators instead of
multiple casskops (this could remain Orange internal if too specific)

We could decide at the end of these discussions the best way forward.
Orange could make PRs on cass-operator, but only if we agree we want the
functionalities :)

If we can sort it out we could end up with a pretty neat operator.

We share a common architecture (operator-sdk), start to know each other
with all these meetings so it should be possible if we want to!

Would that be ok for the community and Datastax?

On 2 Oct 2020, at 14:52, Joshua McKenzie 
mailto:jmcken...@apache.org>> wrote:

What are next steps here?

Maybe we collectively put a table together w/the 2 operators and a list
of
features to compare and contrast? Enumerate the frameworks / dependencies
they have to help form a point of view about the strengths and weaknesses
of each option?

On Tue, Sep 29, 2020 at 10:22 PM, Christopher Bradford https://issues.apache.org/jira/browse/CASSANDRA-15823>

If there are further questions about the project, codebase, architecture,
etc. the team would be happy to dive in to the details and discuss more.

Cheers,
~Chris

Christopher Bradford

On Mon, Sep 28, 2020 at 12:19 PM Patrick McFadin 
mailto:pmcfa...@gmail.com>>
wrote:

I can agree with that Ben. Franck did a good job of outlining CassKop.
Somebody from the cass-operator will be posting something similar and we
can keep it on the mailing list.

Patrick

On Sun, Sep 27, 2020 at 2:16 PM Ben Bromhead 
mailto:b...@instaclustr.com>>
wrote:

Thanks Frank and Stefan.

@Patrick great suggestion and worthwhile getting everything on the table.

One minor change I would advocate for. The SIG has been great to iterate
and interact on the details, but I really think this conversation given

the

nature of the content needs to be on the mailing list. The mailing list

is

really our system of record and the most accessible.

It gives folk time to think and digest, it's asynchronous, easily
searchable and let's be honest, the majority of stakeholders in this are
not US based, so the timing issue then goes away and makes it easier for
people to participate in. I feel like we've made a lot more progress by
simply having this discussion here.

So instead of a presentation, maybe just an email to the ML addressing

the

headings that Patrick identified?

On Fri, Sep 25, 2020 at 7:55 AM Stefan Miklosovic < stefan.miklosovic@
instaclustr.com> wrote:

Hi,

Patrick's suggestion seems good to me.

I won't go into specifics here as I need to genuinely prepare for this.
It
is quite hard to dig deep into the solutions of others and bring some
constructive criticism because it takes a lot of time to study it and
everybody has some "why's" behind it.

To summarize my goals and concerns:

1) We should be as much "Kubernetes operator idiomatic" as possible.
Industry standards, no custom brain-child of this or that group because
they think it is just cool or they just didn't know any better

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[Joshua McKenzie]

I'm a big fan of github milestones for exactly this kind of work. Just as
much process as strictly required to logically group things and align on
scope and nothing more.


On Fri, Oct 16, 2020 at 9:24 AM,  wrote:

> Hi all, sorry for the delay we were busy releasing V1 of CassKop which
> happened this week: https://github.com/Orange-OpenSource/casskop
>
> Now we would like to open the discussions about feature merging and I
> would like to follow Joshua’s proposition: open issues on cass-operator.
>
> As I said, we discuss first and if we find a way forward then we do it!
>
> We will open the issues next week and move forward.
>
> We can discuss them during the next SIG calls from thursday
>
> Franck
>
> On 6 Oct 2020, at 08:02, Ben Bromhead mailto:ben@
> instaclustr.com>> wrote:
>
> Thanks Frank and Christopher.
>
> Sounds like we have a good path to consolidate around!
>
> On Sat, Oct 3, 2020 at 11:12 AM Joshua McKenzie  > wrote:
>
> how to best merge Casskop's features in Cass-operator.
>
> What if we create issues on the gh repo here
> https://github.com/datastax/cass-operator/issues, create a milestone out
> of
> that, and have engineers rally on it to get things merged? We have a few
> engineers focused on k8s ecosystem for Cassandra from the DataStax side
> who'd be happy to collaborate with you folks to get these things in.
>
> On Fri, Oct 02, 2020 at 11:34 AM, mailto:franck.
> de...@orange.com>> wrote:
>
> An update on Orange's point of view following the recent emails:
>
> If we were a newly interested party in running C* in K8s, we would use
> Cass-operator as it comes from Datastax.
>
> The logic would then be that the community embraces it and thanks Datastax
> for offering it!
>
> So, on Orange side, we propose to discuss with Datastax how to best merge
> Casskop's features in Cass-operator. These features are:
> - nodes labelling to map any internal architecture (including network
> specific labels to muti-dc setup)
> - volumes & sidecars management (possibly linked to PodTemplateSpec)
> - backup & restore (we ruled out velero and can share why we went with
> Instaclustr but Medusa could work too)
> - kubectl plugin integration (quite useful on the ops side without an
> admin UI)
> - multiCassKop evolution to drive multiple cass-operators instead of
> multiple casskops (this could remain Orange internal if too specific)
>
> We could decide at the end of these discussions the best way forward.
> Orange could make PRs on cass-operator, but only if we agree we want the
> functionalities :)
>
> If we can sort it out we could end up with a pretty neat operator.
>
> We share a common architecture (operator-sdk), start to know each other
> with all these meetings so it should be possible if we want to!
>
> Would that be ok for the community and Datastax?
>
> On 2 Oct 2020, at 14:52, Joshua McKenzie  jmcken...@apache.org>> wrote:
>
> What are next steps here?
>
> Maybe we collectively put a table together w/the 2 operators and a list of
> features to compare and contrast? Enumerate the frameworks / dependencies
> they have to help form a point of view about the strengths and weaknesses
> of each option?
>
> On Tue, Sep 29, 2020 at 10:22 PM, Christopher Bradford  com
>
> wrote:
>
> Hello Dev list,
>
> I'm Chris Bradford a Product Manager at DataStax working with the
> cass-operator team. For background, we started down the path of developing
> an operator internally to power our C*aaS platform, Astra. Care was taken
> from day 1 to keep anything specific to this product at a layer above
> cass-operator so it could solely focus on the task of operating Cassandra
> clusters. With that being said, every single cluster on Astra is
> provisioned and operated by cass-operator. The value of an advanced
> operator to Cassandra users is tremendous so we decided to open source the
> project (and associated components) with the goal of building a community.
> It absolutely makes sense to offer this project and codebase up for
> donation as a standard / baseline for running C* on Kubernetes.
>
> Below you will find a collection of cass-operator features,
> differentiators, and roadmap / inflight initiatives. Table-stakes Must-have
> functionality for a C* operator
>
> -
>
> Datacenter provisioning
> -
>
> Schedule all pods
> -
>
> Bootstrap nodes in the appropriate order
> -
>
> Seeds
> -
>
> Across racks
> -
>
> etc.
> -
>
> Uniform configuration
> -
>
> Scale-up
> -
>
> Add new nodes in a balanced manner across rack
> -
>
> Scale-down
> -
>
> Remove nodes one at a time across racks
> -
>
> Node recovery
> -
>
> Restart process
> -
>
> Reschedule instance (IE replace node)
> - Replace instance
> -
>
> Specific workflows for seed node replacements
> -
>
> Multi-DC / Multi-Rack
> -
>
> Multi-Region / Multi-K8s Cluster
> -
>
> Note this requires support at a networking layer for pod to pod IP
> connectivity. This may be accomplished within the cluster with CNIs like
> Cilium or extern

Re: Monthly community blog - thoughts?

[Aaron Ploetz]

I think this is an awesome idea, and I'm happy to help in any way that I
can.

Possible post topics:
-(new/existing) features
-common modeling practices
-community member "spotlight"
-tooling (Reaper, Medusa, K8s operator, etc...)

Thanks,

Aaron


On Fri, Oct 16, 2020 at 5:30 AM Horia Mocioi  wrote:

> Sounds good.
>
> How should we send suggestions? Via email or we can do it ourselves?
>
> Regards,
> Horia
>
> On Thu, Oct 15, 2020 at 11:58 PM Erick Ramirez  >
> wrote:
>
> > What a great idea! This is a good signal on how active the community is.
> >
> > I'm happy to help with proof-reading/reviews.
> >
> > P.S. The section on Harry contains HTML code. :)
> >
>

Cassandra 4.0 Status update 2020-10-16

[Joshua McKenzie]

Hello project, and welcome to your much delayed issue of “The Path to
4.0 GA”.We haven’t had these for a while but discussed their value on
the last contributor call, so let’s get back in the saddle.

Link to the freshly renamed JIRA board:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
Top level: We have 2 Alpha issues, 61 Beta issues, and 20 RC issues to
go before GA

Some interesting high level metrics on the release: We have closed a
total of 1341 tickets in 4.0:
https://issues.apache.org/jira/issues/?filter=12348585&jql=project%20%3D%20cassandra%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-alpha1%2C%204.0-alpha2%2C%204.0-alpha3%2C%204.0-alpha4%2C%204.0-beta%2C%204.0-beta1%2C%204.0-beta2%2C%204.0-beta3%2C%204.0-beta4%2C%204.0-rc)%20AND%20resolution%20!%3D%20unresolved
With our outstanding scope of 84 open issues, we have 5.9% by raw
ticket count to go before GA!

Another view: in the past 45 days, here’s our view of our created vs.
closed rate:
https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=Next
The impressive spike in ticket openings was Benjamin tearing through
creating the new testing for metrics so we should expect those to
close out quite rapidly as people focus on them.

[Where you can help]

*No assignee: 19 total
16 Beta issues and 3 RC issues
Please take a look and see if it’s within your skillset to take any of
these on if you have the cycles:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1658
*Needs Reviewer: 8 tickets
5 Beta and 3 RC issues are awaiting review without reviewer:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1659
*Adding tests: 5 tickets (note: Board quick filter added for this)
Benjamin created some child tickets on the 40_Quality_Test epic to
better test our metrics - if you’ve been thinking about getting
involved on the project these are probably great candidates to get
your feet wet and improve the coverage and stability of the system.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&selectedIssue=CASSANDRA-16192&quickFilter=1661&quickFilter=1939&quickFilter=1658
*7-day stall
As we get closer to the release, we should tighten our window on what
we consider “stalled”. There’s a quick filter for “hasn’t been updated
in over a week” which shows just over half the entire open corpus of
work hasn’t moved in the last week. Let’s make it a point to brush up
our gmail filters and workflow habits to keep these from slipping
through the cracks on async handoffs (and from me hounding you on
slack =/)
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1694
Thanks everyone for the continued hard work on the project, and expect
to see these emails from one of your local J's on a weekly basis
starting the week of the 26th.

~Josh

Re: Monthly community blog - thoughts?

[Melissa Logan]

I think this is an awesome idea, and I'm happy to help in any way that I
can.
> Fantastic, thanks!

Possible post topics:
-(new/existing) features
-common modeling practices
-community member "spotlight"
-tooling (Reaper, Medusa, K8s operator, etc...)
> Great ideas. If you have anything to add/amend in the doc, just let me
know. If you can't access, feel free to send my way and I'll merge.

On Fri, Oct 16, 2020 at 10:41 AM Aaron Ploetz  wrote:

> I think this is an awesome idea, and I'm happy to help in any way that I
> can.
>
> Possible post topics:
> -(new/existing) features
> -common modeling practices
> -community member "spotlight"
> -tooling (Reaper, Medusa, K8s operator, etc...)
>
> Thanks,
>
> Aaron
>
>
> On Fri, Oct 16, 2020 at 5:30 AM Horia Mocioi  wrote:
>
> > Sounds good.
> >
> > How should we send suggestions? Via email or we can do it ourselves?
> >
> > Regards,
> > Horia
> >
> > On Thu, Oct 15, 2020 at 11:58 PM Erick Ramirez <
> erick.rami...@datastax.com
> > >
> > wrote:
> >
> > > What a great idea! This is a good signal on how active the community
> is.
> > >
> > > I'm happy to help with proof-reading/reviews.
> > >
> > > P.S. The section on Harry contains HTML code. :)
> > >
> >
>