Open Stack

On 10/12/15 20:05 +0000, Amrith Kumar wrote:
>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.

Ah indeed! I had interpreted it as a hard spec freeze. I don't think a
hard spec freeze is a bad idea but it's harder to enforce and
communicate.

Looks like you guys have it under control, thanks for clarifying. :)
Flavio

>
>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

-- 
@flaper87
Flavio Percoco