Open Stack

Flavio,

The issue we had in the last cycle was that a lot of specs and code arrived for review late in the process and this posed a challenge. The intent this time around was to ensure that there wasn't such a back-end loaded process and that people had a good idea of what is coming down the pike. It is more of a traffic management solution, and one that we are trying for the first time in this cycle. We will get better in the next cycle.

That is my interpretation of the process and the context for my broadcast message. Note that this is not a hard spec freeze and a request for exceptions (which seems to be your interpretation). On the contrary, it is a heads-up to the rest of the Trove team of what is coming down the pike.
 
Thanks,

-amrith

> -----Original Message-----
> From: Flavio Percoco [mailto:flavio at redhat.com]
> Sent: Thursday, December 10, 2015 1:53 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [trove] Upcoming specs and blueprints for
> Trove/Mitaka
> 
> On 10/12/15 18:44 +0000, Vyvial, Craig wrote:
> >Amrith/Victoria,
> >
> >Thanks for the heads up about this these blueprints for the Mitaka cycle.
> This looks like a lot of work but there shouldn’t be a reason to hold back new
> blueprints this early in the cycle if they plan on being completed in Mitaka.
> Can we get these blueprints written up and submitted so that we can get
> them approved by Jan 8th? Due to the holidays i think this makes sense.
> >
> >These blueprints should all be complete and merged by M-3 cut date (Feb
> 29th) for the feature freeze.
> >
> >Let me know if there are concerns around this.
> >
> 
> Sorry for jumping in out of the blue, especially as I haven't been part of the
> process but, wouldn't it be better for Trove to just skips having a hard spec
> freeze in Mitaka and just plan it for N (as Amrith
> proposed) ?
> 
> Having a deadline and then allowing new spec to be proposed (or just a
> bunch of freeze exceptions) is not very effective. Deadlines need to be well
> planned ahead and thoroughly communicated.
> 
> If it was done, I'm sorry. As I mentioned, I wasn't part of the process and I
> just happened to have read Amrith's email.
> 
> Hope the above makes sense,
> Flavio
> 
> >Thanks,
> >-Craig
> >
> >On Dec 10, 2015, at 12:11 PM, Victoria Martínez de la Cruz
> <victoria at vmartinezdelacruz.com<mailto:victoria at vmartinezdelacruz.com>
> > wrote:
> >
> >2015-12-10 13:10 GMT-03:00 Amrith Kumar
> <amrith at tesora.com<mailto:amrith at tesora.com>>:
> >Members of the Trove community,
> >
> >Over the past couple of weeks we have discussed the possibility of an early
> deadline for submission of trove specifications for projects that are to be
> included in the Mitaka release. I understand why we're doing it, and agree
> with the concept. Unfortunately though, there are a number of projects for
> which specifications won't be ready in time for the proposed deadline of
> Friday 12/11 (aka tomorrow).
> >
> >I'd like to that the following projects are in the works and specifications will
> be submitted as soon as possible. Now that we know of the new process, we
> will all be able to make sure that we are better planned in time for the N
> release.
> >
> >Blueprints have been registered for these projects.
> >
> >The projects in question are:
> >
> >Cassandra:
> >        - enable/disable/show root
> (https://blueprints.launchpad.net/trove/+spec/cassandra-database-user-
> functions)
> >        - Clustering
> >(https://blueprints.launchpad.net/trove/+spec/cassandra-cluster)
> >
> >MariaDB:
> >        - Clustering (https://blueprints.launchpad.net/trove/+spec/mariadb-
> clustering)
> >        - GTID replication
> >(https://blueprints.launchpad.net/trove/+spec/mariadb-gtid-replication)
> >
> >Vertica:
> >        - Add/Apply license
> (https://blueprints.launchpad.net/trove/+spec/vertica-licensing)
> >        - User triggered data upload from Swift
> (https://blueprints.launchpad.net/trove/+spec/vertica-bulk-data-load)
> >        - Cluster grow/shrink
> (https://blueprints.launchpad.net/trove/+spec/vertica-cluster-grow-shrink)
> >        - Configuration Groups
> (https://blueprints.launchpad.net/trove/+spec/vertica-configuration-
> groups)
> >        - Cluster Anti-affinity
> >(https://blueprints.launchpad.net/trove/+spec/vertica-cluster-anti-affi
> >nity)
> >
> >Hbase and Hadoop based databases:
> >        - Extend Trove to Hadoop based databases, starting with HBase
> >(https://blueprints.launchpad.net/trove/+spec/hbase-support)
> >
> >Specifications in the trove-specs repository will be submitted for review as
> soon as they are available.
> >
> >Thanks,
> >
> >-amrith
> >
> >
> >
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe<http://Op
> >enStack-dev-request at lists.openstack.org/?subject:unsubscribe>
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >Hi all,
> >
> >I'd like to add the feature "Add backup strategy for Ceph backends" [0] to
> this list.
> >
> >Thanks,
> >
> >Victoria
> >
> >[0]
> >https://blueprints.launchpad.net/trove/+spec/implement-ceph-as-
> backup-o
> >ption
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-
> request@
> >lists.openstack.org>?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> --
> @flaper87
> Flavio Percoco
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev