Re: [VOTE] Development Approach for Apache Cassandra Management process

[Eric Evans]

On Wed, Sep 12, 2018 at 10:19 AM sankalp kohli  wrote:
>
> Hi,
> Community has been discussing about Apache Cassandra Management process
> since April and we had lot of discussion about which approach to take to
> get started. Several contributors have been interested in doing this and we
> need to make a decision of which approach to take.
>
> The current approaches being evaluated are
> a. Donate an existing project to Apache Cassandra like Reaper. If this
> option is selected, we will evaluate various projects and see which one
> fits best.
> b. Take a piecemeal approach and use the features from different OSS
> projects and build a new project.
>
> Available options to vote
> a. +1 to use existing project.
> b. +1 to take piecemeal approach
> c  -1 to both
> d +0 I dont mind either option

As others have pointed out, I think we're placing too much of an
emphasis on voting; What we need is consensus, not a majority ruling.
Obtaining consensus can be difficult, frustrating, and time-consuming,
but IMO always worth it.

My interpretation of the discussion is that there was at least
consensus on the value of a project-supported management stack, as
well as (I think) the notion that it should be kept loosely coupled to
the database, beyond that things seem contentious.

Assuming I'm not wrong, and there is consensus on a loosely-coupled
project, why do we need to rush a decision on inclusion?  What
prevents those who are vested in one approach (or existing project) or
another from working on what they think best?  I suspect developing
consensus here would be a lot easier if we were talking about
something a bit more concrete.

-- 
Eric Evans
john.eric.ev...@gmail.com

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

Re: Proposing an Apache Cassandra Management process

[sankalp kohli]

How about we start with a few basic features in side car. How about
starting with this
1. Bulk nodetool commands: User can curl any sidecar and be able to run a
nodetool command in bulk across the cluster.
:/bulk/nodetool/tablestats?arg0=keyspace_name.table_name&arg1=

And later
2: Health checks.

On Thu, Sep 13, 2018 at 11:34 AM dinesh.jo...@yahoo.com.INVALID
 wrote:

> I will update the document to add that point. The document did not mean to
> serve as a design or architectural document but rather something that would
> spark a discussion on the idea.
> Dinesh
>
> On Thursday, September 13, 2018, 10:59:34 AM PDT, Jonathan Haddad <
> j...@jonhaddad.com> wrote:
>
>  Most of the discussion and work was done off the mailing list - there's a
> big risk involved when folks disappear for months at a time and resurface
> with big pile of code plus an agenda that you failed to loop everyone in
> on. In addition, by your own words the design document didn't accurately
> describe what was being built.  I don't write this to try to argue about
> it, I just want to put some perspective for those of us that weren't part
> of this discussion on a weekly basis over the last several months.  Going
> forward let's keep things on the ML so we can avoid confusion and
> frustration for all parties.
>
> With that said - I think Blake made a really good point here and it's
> helped me understand the scope of what's being built better.  Looking at it
> from a different perspective it doesn't seem like there's as much overlap
> as I had initially thought.  There's the machinery that runs certain tasks
> (what Joey has been working on) and the user facing side of exposing that
> information in management tool.
>
> I do appreciate (and like) the idea of not trying to boil the ocean, and
> working on things incrementally.  Putting a thin layer on top of Cassandra
> that can perform cluster wide tasks does give us an opportunity to move in
> the direction of a general purpose user-facing admin tool without
> committing to trying to write the full stack all at once (or even make
> decisions on it now).  We do need a sensible way of doing rolling restarts
> / scrubs / scheduling and Reaper wasn't built for that, and even though we
> can add it I'm not sure if it's the best mechanism for the long term.
>
> So if your goal is to add maturity to the project by making cluster wide
> tasks easier by providing a framework to build on top of, I'm in favor of
> that and I don't see it as antithetical to what I had in mind with Reaper.
> Rather, the two are more complementary than I had originally realized.
>
> Jon
>
>
>
>
> On Thu, Sep 13, 2018 at 10:39 AM dinesh.jo...@yahoo.com.INVALID
>  wrote:
>
> > I have a few clarifications -
> > The scope of the management process is not to simply run repair
> > scheduling. Repair scheduling is one of the many features we could
> > implement or adopt from existing sources. So could we please split the
> > Management Process discussion and the repair scheduling?
> > After re-reading the management process proposal, I see we missed to
> > communicate a basic idea in the document. We wanted to take a pluggable
> > approach to various activities that the management process could perform.
> > This could accommodate different implementations of common activities
> such
> > as repair. The management process would provide the basic framework and
> it
> > would have default implementations for some of the basic activities. This
> > would allow for speedier iteration cycles and keep things extensible.
> > Turning to some questions that Jon and others have raised, when I +1, my
> > intention is to fully contribute and stay with this community. That said,
> > things feel rushed for some but for me it feels like analysis paralysis.
> > We're looking for actionable feedback and to discuss the management
> process
> > _not_ repair scheduling solutions.
> > Thanks,
> > Dinesh
> >
> >
> >
> > On Sep 12, 2018, at 6:24 PM, sankalp kohli 
> wrote:
> > Here is a list of open discussion points from the voting thread. I think
> > some are already answered but I will still gather these questions here.
> >
> > From several people:
> > 1. Vote is rushed and we need more time for discussion.
> >
> > From Sylvain
> > 2. About the voting process...I think that was addressed by Jeff Jirsa
> and
> > deserves a separate thread as it is not directly related to this thread.
> > 3. Does the project need a side car.
> >
> > From Jonathan Haddad
> > 4. Are people doing +1 willing to contribute
> >
> > From Jonathan Ellis
> > 5. List of feature set, maturity, maintainer availability from Reaper or
> > any other project being donated.
> >
> > Mick Semb Wever
> > 6. We should not vote on these things and instead build consensus.
> >
> > Open Questions from this thread
> > 7. What technical debts we are talking about in Reaper. Can someone give
> > concrete examples.
> > 8. What is the timeline of donating Reaper to Apache Cassandra.
> >

Re: QA signup

[Scott Andreas]

@Mick, thanks for your reply re: publishing snapshots/nightlies. In terms of 
what’s needed to configure these, would it be automation around building 
release artifacts, publishing jars to the Maven snapshots repo, and to 
dist/dev/cassandra on dist.apache.org for binary 
artifacts?

@Joey Thanks! Jason’s shown me what I was missing in Confluence. Can you try 
creating a page and letting me know if you’re able? Feel free to create any 
pages you think appropriate.

I’ve added permissions for the "cassandra-committers” group, and for the PMC 
members and committers who have accounts on 
cwiki.apache.org [1]. For those who don’t have a cwiki 
account but would like write access, please sign up and send Jason or myself a 
message; we can enable write perms: 
https://cwiki.apache.org/confluence/signup.action

– Scott

–––

[1] PMC members and committers with write access added:
– Jake Luciani
– Jason Brown
– Jonathan Ellis
– Jake Farrell
– Jeff Jirsa
– Jun Rao
– Matthieu Riou
– Sylvain Lebresna
– Avinash Lakshman
– Johan Oskarsson
– Mick Semb Wever


On September 12, 2018 at 4:44:51 PM, Joseph Lynch 
(joe.e.ly...@gmail.com) wrote:

> In looking at the Confluence space restrictions, it appears the main page is 
> open for editing and I don't see restrictions on page creation; can you try 
> to sign in, create one, and let me know if that doesn't work?

I signed in and went to "Jira reports" and then tried to hit "Add Jira
Report" and it said "Sorry you don't have permission to create
content. Contact your space administrator to request access". Also if
I just go to the Cassandra space there is no "Create" button in the in
the top left where it normally is, all I see when logged on in the
Cassandra space is "Spaces" and "People".

> I'm planning to create a few more pages for a couple testing tracks in a few 
> days, some of which are described here [1]. Eager to collaborate on these as 
> well.

Please let me know if you create one for internode messaging, we have
(I think valuable) data/methods from last Wednesday we can share. I've
started leaving the results we have so far as well as the methodology
we used at https://issues.apache.org/jira/browse/CASSANDRA-14746 with
the label "4.0-QA" but I can copy and paste anywhere we decide to put
these things.

-Joey

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

Re: QA signup

[Mick Semb Wever]

Scott,

> @Mick, thanks for your reply re: publishing snapshots/nightlies. In 
> terms of what’s needed to configure these, would it be automation around 
> building release artifacts, publishing jars to the Maven snapshots repo, …


Maven artefacts are deployed to the ASF snapshot repository in Nexus.
The short of it is to add credentials for `apache.snapshots.https` to 
~/.m2/settings.xml and run `ant publish`. 

It looks like `ant publish` won't run when it's not a release, but otherwise 
the maven deploy properties in `build.xml` look correct for snapshots.

I haven't looked into how to automate this in Jenkins in regards to the 
settings.xml credentials and the gpg signing. 

For info at: http://www.apache.org/dev/publishing-maven-artifacts.html

I question I have is who are we targeting with maven snapshots? Is this an 
audience that can easily enough be building the jars themselves to test during 
the feature freeze period?


> and to dist/dev/cassandra on dist.apache.org for  binary artifacts?


This is a simpler task, just upload (`svn commit`) the nightly binaries to 
https://dist.apache.org/repos/dist/dev/cassandra/  

See  https://www.apache.org/legal/release-policy.html#host-rc

regards,
Mick

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