settingsLogin | Registersettings

[openstack-dev] [trove][tc][all] Trove restart - next steps

0 votes

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

  • Fix the gate

    • Update currently failing jobs, create xenial based images
    • Fix gate jobs that have gone stale (non-voting, no one paying
      attention)
  • Bug triage

    • Bugs in launchpad are really out of date, assignments to
      people who are no longer active, bugs that are really support
      requests, etc.,
    • Prioritize fixes for Queens and beyond
  • Get more active reviewers

    • There seems to still be a belief that 'contributing' means
      'fixing bugs'. There is much more value in actually doing
      reviews.
    • Get at least a three member active core review team by the
      end of the year.
  • Complete Python 3 support

    • Currently not complete; especially on the guest side
  • Community Goal, migrate to oslo.policy

  • Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the
chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.

-amrith

[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Aug 15, 2017 in openstack-dev by amrith.kumar_at_gmai (3,580 points)   2 3

4 Responses

0 votes

One idea I found interesting from the past discussion was the approach that the user need is a database with a connection string.

How feasible is the approach where we are provisioning access to a multi-tenant database infrastructure rather than deploying a VM with storage and installing a database?

This would make the service delivery (monitoring, backup, upgrades) in the responsibility of the cloud provider rather than the end user. Some quota/telemetry would be needed to allocate costs to the project.

Tim

From: Amrith Kumar amrith.kumar@gmail.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

  • Fix the gate

    • Update currently failing jobs, create xenial based images
    • Fix gate jobs that have gone stale (non-voting, no one paying
      attention)
  • Bug triage

    • Bugs in launchpad are really out of date, assignments to
      people who are no longer active, bugs that are really support
      requests, etc.,
    • Prioritize fixes for Queens and beyond
  • Get more active reviewers

    • There seems to still be a belief that 'contributing' means
      'fixing bugs'. There is much more value in actually doing
      reviews.
    • Get at least a three member active core review team by the
      end of the year.
  • Complete Python 3 support

    • Currently not complete; especially on the guest side
  • Community Goal, migrate to oslo.policy

  • Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.
-amrith

[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 15, 2017 by Tim_Bell (16,440 points)   1 8 10
0 votes

Tim,

This is an idea that was discussed at a trove midcycle a long time back
(Juno midcycle, 2014). It came up briefly in the Kilo midcycle as well but
was quickly rejected again.

I've added it to the list of topics for discussion at the PTG. If others
want to add topics to that list, the etherpad is at
https://etherpad.openstack.org/p/trove-queens-ptg​

Thanks!

-amrith

On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell Tim.Bell@cern.ch wrote:

One idea I found interesting from the past discussion was the approach
that the user need is a database with a connection string.

How feasible is the approach where we are provisioning access to a
multi-tenant database infrastructure rather than deploying a VM with
storage and installing a database?

This would make the service delivery (monitoring, backup, upgrades) in the
responsibility of the cloud provider rather than the end user. Some
quota/telemetry would be needed to allocate costs to the project.

Tim

*From: *Amrith Kumar amrith.kumar@gmail.com
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" openstack-dev@lists.openstack.org
*Date: *Tuesday, 15 August 2017 at 17:44
*To: *"OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
*Subject: *[openstack-dev] [trove][tc][all] Trove restart - next steps

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

  • Fix the gate

    • Update currently failing jobs, create xenial based images
    • Fix gate jobs that have gone stale (non-voting, no one paying
      attention)
  • Bug triage

    • Bugs in launchpad are really out of date, assignments to
      people who are no longer active, bugs that are really support
      requests, etc.,
    • Prioritize fixes for Queens and beyond
  • Get more active reviewers

    • There seems to still be a belief that 'contributing' means
      'fixing bugs'. There is much more value in actually doing
      reviews.
    • Get at least a three member active core review team by the
      end of the year.
  • Complete Python 3 support

    • Currently not complete; especially on the guest side
  • Community Goal, migrate to oslo.policy

  • Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the
chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.

-amrith

[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 15, 2017 by amrith.kumar_at_gmai (3,580 points)   2 3
0 votes

Thanks for the info.

Can you give a summary for reasons for why this was not a viable approach?

Tim

From: Amrith Kumar amrith.kumar@gmail.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Tuesday, 15 August 2017 at 23:09
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

Tim,
This is an idea that was discussed at a trove midcycle a long time back (Juno midcycle, 2014). It came up briefly in the Kilo midcycle as well but was quickly rejected again.
I've added it to the list of topics for discussion at the PTG. If others want to add topics to that list, the etherpad is at https://etherpad.openstack.org/p/trove-queens-ptg​

Thanks!

-amrith

On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell Tim.Bell@cern.ch wrote:
One idea I found interesting from the past discussion was the approach that the user need is a database with a connection string.

How feasible is the approach where we are provisioning access to a multi-tenant database infrastructure rather than deploying a VM with storage and installing a database?

This would make the service delivery (monitoring, backup, upgrades) in the responsibility of the cloud provider rather than the end user. Some quota/telemetry would be needed to allocate costs to the project.

Tim

From: Amrith Kumar amrith.kumar@gmail.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

  • Fix the gate

    • Update currently failing jobs, create xenial based images
    • Fix gate jobs that have gone stale (non-voting, no one paying
      attention)
  • Bug triage

    • Bugs in launchpad are really out of date, assignments to
      people who are no longer active, bugs that are really support
      requests, etc.,
    • Prioritize fixes for Queens and beyond
  • Get more active reviewers

    • There seems to still be a belief that 'contributing' means
      'fixing bugs'. There is much more value in actually doing
      reviews.
    • Get at least a three member active core review team by the
      end of the year.
  • Complete Python 3 support

    • Currently not complete; especially on the guest side
  • Community Goal, migrate to oslo.policy

  • Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.
-amrith

[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 16, 2017 by Tim_Bell (16,440 points)   1 8 10
0 votes

Tim,

Sorry for the delay getting back to you.

Different database vendors give you different levels of isolation within your database itself, and making a database truly multi-tenant was something that we did not want to get into. The discussion centered around the benefits of such a use-case and thing that drove the decision to not go down the path of multi-tenancy was that if Trove provided a VM per database instance, implementing multi-tenancy is something that a trove user can in fact do for themselves.

At the time when we thought about this, the critical things on the horizon were to implement replication and clustering, and add support for more capabilities and databases. Therefore multi-tenancy did not rise very far on the list.

Looking at it again, I like the idea but again think there are higher priority things I’d like to focus on first. In digging us out of the current ditch that we are in, multi-tenancy may not be the thing that would materially benefit the project.

But, we shall discuss in a week or so at PTG.

--

Amrith Kumar
amrith.kumar@gmail.com amrith.kumar@gmail.com

From: Tim Bell [mailto:Tim.Bell@cern.ch]
Sent: Wednesday, August 16, 2017 1:45 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

Thanks for the info.

Can you give a summary for reasons for why this was not a viable approach?

Tim

From: Amrith Kumar <amrith.kumar@gmail.com amrith.kumar@gmail.com >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >
Date: Tuesday, 15 August 2017 at 23:09
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

Tim,

This is an idea that was discussed at a trove midcycle a long time back (Juno midcycle, 2014). It came up briefly in the Kilo midcycle as well but was quickly rejected again.

I've added it to the list of topics for discussion at the PTG. If others want to add topics to that list, the etherpad is at https://etherpad.openstack.org/p/trove-queens-ptg​

Thanks!

-amrith

On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell <Tim.Bell@cern.ch Tim.Bell@cern.ch > wrote:

One idea I found interesting from the past discussion was the approach that the user need is a database with a connection string.

How feasible is the approach where we are provisioning access to a multi-tenant database infrastructure rather than deploying a VM with storage and installing a database?

This would make the service delivery (monitoring, backup, upgrades) in the responsibility of the cloud provider rather than the end user. Some quota/telemetry would be needed to allocate costs to the project.

Tim

From: Amrith Kumar <amrith.kumar@gmail.com amrith.kumar@gmail.com >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >
Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >
Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

  • Fix the gate

    • Update currently failing jobs, create xenial based images
    • Fix gate jobs that have gone stale (non-voting, no one paying
      attention)
  • Bug triage

    • Bugs in launchpad are really out of date, assignments to
      people who are no longer active, bugs that are really support
      requests, etc.,
    • Prioritize fixes for Queens and beyond
  • Get more active reviewers

    • There seems to still be a belief that 'contributing' means
      'fixing bugs'. There is much more value in actually doing
      reviews.
    • Get at least a three member active core review team by the
      end of the year.
  • Complete Python 3 support

    • Currently not complete; especially on the guest side
  • Community Goal, migrate to oslo.policy

  • Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.

-amrith

[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 3, 2017 by amrith.kumar_at_gmai (3,580 points)   2 3
...