Greetings, Trove team!
As you may be aware, I've been working with other folks in the community
on documenting a vision for OpenStack clouds (formerly known as the
'Technical Vision') - essentially to interpret the mission statement in
long-form, in a way that we can use to actually help guide
Hello everyone,
A new release candidate for trove for the end of the Rocky
cycle is available! You can find the source code tarball at:
https://tarballs.openstack.org/trove/
Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally re
Hello everyone,
A new release candidate for trove-dashboard for the end of the Rocky
cycle is available! You can find the source code tarball at:
https://tarballs.openstack.org/trove-dashboard/
Unless release-critical issues are found that warrant a release
candidate respin, this candidate
Dariusz Krol,
That's great, thanks. Please submit your nomination asap, the deadline is
today(2018-07-31 23:45:00 UTC). For detailed guidance about nomination,
please refer to https://governance.openstack.org/election/.
I think we need some work on https://review.openstack.org/#/c/586528/2, and
w
Hello Zhao Chao,
after some internal discussion, I will do the nomination if you decided
not to nominate yourself. Thanks for letting know you will be still
available in the next release cycle.
Regarding commits I would recommend to consider also
https://review.openstack.org/#/c/586528/2 .
Dariusz Krol wrote:
[...]
On the other hand, I can also understand the lack of time to be a PTL
since it requires probably a lot of time to coordinate all the work.
Let’s wait for Chao Zhao to give his opinion on the topic :)
If the PTL delegates the most time-intensive work (release liaison
I found I made a mistake on the subject of this mail, so I corrected it in
my last response, hope this won't make any further confusion.
On Mon, Jul 30, 2018 at 9:26 AM, 赵超 wrote:
> Since the new folks are still so new - if this works for you - I would
>> recommend continuing on as the official
>
> Since the new folks are still so new - if this works for you - I would
> recommend continuing on as the official PTL for one more release, but with
> the
> understanding that you would just be around to answer questions and give
> advice
> to help the new team get up to speed. That should hopef
Hi Sean,
This is good point. It would be great to have some help especially to start. We have some experience with contributing to openstack and we are working with gerrit on daily basis so there is no problem with technical aspects. However, it takes some time for changes to be reviewed an
> >
> > A good news is recently a team from Samsung R&D Center in Krakow, Poland
> > joined us, they're building a product on OpenStack, have done improvments
> > on Trove(internally), and now interested in contributing to the community,
> > starting by migrating the intergating tests to the tempes
Hello All,
as a member of Samsung R&D Center in Krakow, I would like to confirm
that we are very interested in Trove development.
We also notices that Trove project has a small team now and that
community around Trove becomes smaller with each release which is a
shame since it is a great proj
cc to the Trove team members and guys from Samsung R&D Center in Krakow,
Poland privately, so anyone of them who are not reading the ML could also
be notified.
On Thu, Jul 26, 2018 at 12:09 AM, 赵超 wrote:
> Hi All,
>
> Trove currently has a really small team, and all the active team members
> are
Hi All,
Trove currently has a really small team, and all the active team members
are from China, we had some good discussions during the Rocky online PTG
meetings[1], and the goals were arranged and priorited [2][3]. But it's sad
that none of us could focus on the project, and the number of patche
Hi,
Sorry for forgetting to discuss this on the last meeting, as here in China
we'll on a vacation for Qingming Festival from April 5th, some core members
may not be able to attend the meeting, so let's skip it, the next meeting
will be Wednesday, April 11th, 2018.
--
To be free as in freedom.
_
Thanks for the kind reminder, still enjoy my Chinese New Year holidays, wish
you the best luck in the new year :)
From Fan’s plastic iPhone
在 2018年2月16日,02:16,Manoj Kumar mailto:kuma...@us.ibm.com>>
写道:
I would encourage everyone who is interested in providing input into the Rocky
planning c
I would encourage everyone who is interested in providing input into the
Rocky planning cycle for Trove to put their ideas into the etherpad at:
https://etherpad.openstack.org/p/trove-ptg-rocky
There are a good number of topics posted already. We would welcome input
from operators as well.
We
Hello everyone,
A new release candidate for trove for the end of the Queens
cycle is available! You can find the source code tarball at:
https://tarballs.openstack.org/trove/
Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally r
Hello everyone,
A new release candidate for trove-dashboard for the end of the Queens
cycle is available! You can find the source code tarball at:
https://tarballs.openstack.org/trove-dashboard/
Unless release-critical issues are found that warrant a release
candidate respin, this candidat
On 2018-01-26 22:22, Manoj Kumar wrote:
> Initial indication was provided in July last year, that the
> trove-integration repository was going away.
> All the elements have been merged into trove, and are being maintained
> there.
>
> I do not believe anyone spoke up then. If anyone is depending
Initial indication was provided in July last year, that the
trove-integration repository was going away.
All the elements have been merged into trove, and are being maintained
there.
I do not believe anyone spoke up then. If anyone is depending on the
separate repository, do speak up.
Cheers,
What a pity.
Thanks so much for your remarkable work for trove in the last cycle, it’s my
pleasure to work with you. Wish you the best!
From Fan’s plastic iPhone
On 25 Jan 2018, at 00:24, Manoj Kumar
mailto:kuma...@us.ibm.com>> wrote:
I have had the good fortune to be the PTL for Trove the la
I have had the good fortune to be the PTL for Trove the last cycle.
During this period, I was able to oversee a resurgence of community
participation in Trove.
As the project continues to evolve, it could use some new leadership.
I wanted to clear the path for others to run.
So I do not intend t
+1 and congrats!
On 10/01/18 12:10, Manoj Kumar wrote:
> I would like to announce the following changes to the Trove core
> reviewers:
>
> -amrith
> +maciej.jozefczyk
> +fanzhang
>
> Amrith's stewardship of Trove and active contributions over the last
> several cycles would be missed dearly.
> Wo
I would like to announce the following changes to the Trove core
reviewers:
-amrith
+maciej.jozefczyk
+fanzhang
Amrith's stewardship of Trove and active contributions over the last
several cycles would be missed dearly.
Would like to welcome Fan and Maciej.
- Manoj
___
Hi,all:
I want to use ceph rgw to replace swift,who has a plan to do this?
保密:本函仅供收件人使用,如阁下并非抬头标明的收件人,请您即刻删除本函,勿以任何方式使用及传播,并请您能将此误发情形通知发件人,谢谢!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
Hi,all
When I resize mysql replica,trove will create a new configuration with
new flavor,but It losts a step to attach replica template configuration whitch
is excuted while replica instance is created.how to fixed?attach replica
configuration again or remove the codes just like this li
I would like to announce the following changes to the Trove core
reviewers:
+jian.song
-mariamj
Mariam has moved on to other projects and unfortunately has not been able
to contribute recently.
Jian Song has been an active contributor/reviewer for the last few cycles.
- Manoj
__
Agreed, please also see[1].
-amrith
[1] https://review.openstack.org/515084
On Wed, Oct 25, 2017 at 3:28 AM, Andreas Jaeger wrote:
> Trove team,
>
> with the retirement of stable/newton, you can now retire
> trove-integration AFAIU.
>
> For information on what to do, see:
> https://docs.opens
Trove team,
with the retirement of stable/newton, you can now retire
trove-integration AFAIU.
For information on what to do, see:
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
I just pushed out two changes for stable/newton retirement that also
take care of step 1 of th
Pl
ease join me in welcoming Samuel Matzek, Luke Browning and Manoj Kumar to
the Trove core team.
-amrith
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.or
Hi:
I am working in Openstack’s upgrade,but I have no idea about trove-GA
upgrade.I find a bp,whitch try to solve this problem,the link is:
https://wiki.openstack.org/wiki/Trove-Guest-Agent-Upgrades
https://blueprints.launchpad.net/trove/+spec/upgrade-guestagent
but it seems to
The amount of time taken to create a trove instance (or cluster) is largely
related to how long it takes to create a nova instance of the same size.
So, how long does it take to create a nova instance of the same size on
your system?
Does your trove image install the database statically into the i
Hi:
it will take 8 minutes to create a mysql instance, and will take 16 minutes to
create mysql cluster, which have one master and one slave
保密:本函仅供收件人使用,如阁下并非抬头标明的收件人,请您即刻删除本函,勿以任何方式使用及传播,并请您能将此误发情形通知发件人,谢谢!
__
OpenStack Dev
ern.ch]
Sent: Wednesday, August 16, 2017 1:45 PM
To: OpenStack Development Mailing List (not for usage questions)
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?
(not for usage questions)"
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
uesday, 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
t for usage questions)"
Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps
Now that we have successfully navigated the Pike release and branched
the t
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
Hello everyone,
A new release candidate for trove-dashboard for the end of the Pike
cycle is available! You can find the source code tarball at:
https://tarballs.openstack.org/trove-dashboard/
Unless release-critical issues are found that warrant a release
candidate respin, this candidate
Hello everyone,
A new release candidate for trove for the end of the Pike
cycle is available! You can find the source code tarball at:
https://tarballs.openstack.org/trove/
Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally rel
Matt, we're trying our best to and the reason they were (recently) moved
back to NON-experimental is that in moving them to experimental, no one
monitored them.
Yes, I am trying to get them to voting and like everything else in Trove,
we could use some help.
Yes, I realize that there are no eleme
I don't dabble in Trove-land often but today I pushed a change and was
watching it in zuul, and noticed that the change runs 26 jobs in the
check queue. Several of those (cassandra, couch, mongo, percona) all
failed nearly immediately with something in the diskimage builder, like
this:
http:/
Doug,
I agree, VM/baremetal, shared VM, object for backup storage or block device
for backup storage, those are implementation choices. We should not have
quota/billing depend on those; Trove should expose counters and
space-time-products of the things that Trove users should be billed for. At
iss
Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove
Kevin,
In interests of 'keeping it simple', I'm going to try and prioritize the
use-cases and pick implementation strategies which target the higher priorit
uota then the hosts can actually
> handle.
>
> Thanks,
> Kevin
>
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Wednesday, July 12, 2017 6:57 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] [trove][all][tc] A proposal to
k-dev
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove
Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500:
> All:
>
> First, let me thank all of you who responded and provided feedback
> on what I wrote. I've summarized what I heard b
Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500:
> All:
>
> First, let me thank all of you who responded and provided feedback
> on what I wrote. I've summarized what I heard below and am posting
> it as one consolidated response rather than responding to each
> of your messages
All:
First, let me thank all of you who responded and provided feedback
on what I wrote. I've summarized what I heard below and am posting
it as one consolidated response rather than responding to each
of your messages and making this thread even deeper.
As I say at the end of this email, I will
it will cause people to walk away from the community and likely
> OpenStack as well.
>
> - Manoj
>
>
>
> From:Amrith Kumar
> To:"OpenStack Development Mailing List (not for usage questions)"
>
> Date:
r
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 06/18/2017 06:41 AM
Subject: [openstack-dev] [trove][all][tc] A proposal to rearchitect
Trove
Trove has evolved rapidly over the past several years, since integration
in IceHouse when it only supported sing
he OpenStack projects as a lot
>>> of its functionality no longer has to be implemented in each project.
>>>
>>
>> I don't disagree with the goal of being able to rely on Kubernetes for
>> many things. But relying on Kubernetes doesn't solve the "I want some
>> easy-to-i
s point.
>
Please keep the conversation going.
>
> Thanks,
> Kevin
>
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Thursday, June 22, 2017 10:05 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trov
z [thie...@openstack.org]
Sent: Thursday, June 22, 2017 12:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove
Fox, Kevin M wrote:
[...]
If you build a Tessmaster clone just to do mariadb, then you share nothing with
the other co
On 23/06/17 05:31, Thierry Carrez wrote:
Zane Bitter wrote:
But back in the day we had a process (incubation) for adding stuff to
OpenStack that it made sense to depend on being there. It was a highly
imperfect process. We got rid of that process with the big tent reform,
but didn't really repla
Zane Bitter wrote:
> But back in the day we had a process (incubation) for adding stuff to
> OpenStack that it made sense to depend on being there. It was a highly
> imperfect process. We got rid of that process with the big tent reform,
> but didn't really replace it with anything at all. Tags nev
Perhaps you are referring to me with the above? As I said on Twitter,
"Make your #OpenStack project usable by and useful for things outside of
the OpenStack ecosystem. Fewer deps. Do one thing well. Solid APIs."
I don't think that the above leads to "further fracturing OpenS
far away from discussing Trove at this point.
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, June 22, 2017 10:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove
On 06/22/201
> -Original Message-
> From: Zane Bitter [mailto:zbit...@redhat.com]
> Sent: June-20-17 4:57 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect
> Trove
>
> On 20/06/17 11:45, Jay Pipes wrote:
&
tl;dr - I think Trove's successor has a future, but there are two
conflicting ideas presented and Trove should pick one or the other.
Excerpts from Amrith Kumar's message of 2017-06-18 07:35:49 -0400:
>
> We have learned a lot from v1, and the hope is that we can address that in
> v2. Some of the
PIs."
I don't think that the above leads to "further fracturing OpenStack". I
think it leads to solid, reusable components.
Best,
-jay
Thanks,
Kevin
____________
From: Thierry Carrez [thie...@openstack.org]
Sent: Thursday, June 22, 2017 12:58 AM
To: openstack-dev@lists.o
collaboration for features. I fear the new push for letting
> projects run standalone will make this worse, not better, further
> fracturing OpenStack.
>
> Thanks,
> Kevin
>
> From: Thierry Carrez [thie...@openstack.org]
> Sent: Thu
__
From: Thierry Carrez [thie...@openstack.org]
Sent: Thursday, June 22, 2017 12:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove
Fox, Kevin M wrote:
> [...]
> If you build a Tessmaster clone just to do mariadb, then you
Fox, Kevin M wrote:
> [...]
> If you build a Tessmaster clone just to do mariadb, then you share nothing
> with the other communities and have to reinvent the wheel, yet again.
> Operators load increases because the tool doesn't function like other tools.
>
> If you rely on a container orchestra
ources (TPR) and would make Trove entirely
> stateless. k8s maintains all state for everything in etcd.
>
> Please consider this architecture.
>
> Thanks,
> Kevin
>
> --
> *From:* Amrith Kumar [amrith.ku...@gmail.com]
> *Sent:* Sunday, Ju
penStack on k8s could use it to deploy the rest of
OpenStack. Even more sharing.
Thanks,
Kevin
From: Thierry Carrez [thie...@openstack.org]
Sent: Wednesday, June 21, 2017 1:52 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][all]
On 21/06/17 01:49, Mark Kirkwood wrote:
On 21/06/17 02:08, Jay Pipes wrote:
On 06/20/2017 09:42 AM, Doug Hellmann wrote:
Does "service VM" need to be a first-class thing? Akanda creates
them, using a service user. The VMs are tied to a "router" which
is the billable resource that the user und
On Wed, Jun 21, 2017 at 1:52 AM, Thierry Carrez wrote:
> Zane Bitter wrote:
>> [...]
>> Until then it seems to me that the tradeoff is between decoupling it
>> from the particular cloud it's running on so that users can optionally
>> deploy it standalone (essentially Vish's proposed solution for t
Zane Bitter wrote:
> [...]
> Until then it seems to me that the tradeoff is between decoupling it
> from the particular cloud it's running on so that users can optionally
> deploy it standalone (essentially Vish's proposed solution for the *aaS
> services from many moons ago) vs. decoupling it from
On 21/06/17 02:08, Jay Pipes wrote:
On 06/20/2017 09:42 AM, Doug Hellmann wrote:
Does "service VM" need to be a first-class thing? Akanda creates
them, using a service user. The VMs are tied to a "router" which
is the billable resource that the user understands and interacts with
through the A
On 20/06/17 11:45, Jay Pipes wrote:
Good discussion, Zane. Comments inline.
++
On 06/20/2017 11:01 AM, Zane Bitter wrote:
On 20/06/17 10:08, Jay Pipes wrote:
On 06/20/2017 09:42 AM, Doug Hellmann wrote:
Does "service VM" need to be a first-class thing? Akanda creates
them, using a service
Excerpts from Jay Pipes's message of 2017-06-20 10:08:54 -0400:
> On 06/20/2017 09:42 AM, Doug Hellmann wrote:
> > Does "service VM" need to be a first-class thing? Akanda creates
> > them, using a service user. The VMs are tied to a "router" which
> > is the billable resource that the user unders
On 06/20/2017 11:45 AM, Jay Pipes wrote:
Good discussion, Zane. Comments inline.
On 06/20/2017 11:01 AM, Zane Bitter wrote:
2) The database VMs are created in a project belonging to the operator
of the service. They're connected to the user's network through
, and isolated from other users
Good discussion, Zane. Comments inline.
On 06/20/2017 11:01 AM, Zane Bitter wrote:
On 20/06/17 10:08, Jay Pipes wrote:
On 06/20/2017 09:42 AM, Doug Hellmann wrote:
Does "service VM" need to be a first-class thing? Akanda creates
them, using a service user. The VMs are tied to a "router" which
On 20/06/17 10:08, Jay Pipes wrote:
On 06/20/2017 09:42 AM, Doug Hellmann wrote:
Does "service VM" need to be a first-class thing? Akanda creates
them, using a service user. The VMs are tied to a "router" which
is the billable resource that the user understands and interacts with
through the AP
On 18/06/17 07:35, Amrith Kumar wrote:
Trove has evolved rapidly over the past several years, since integration
in IceHouse when it only supported single instances of a few databases.
Today it supports a dozen databases including clusters and replication.
The user survey [1] indicates that whi
On 06/20/2017 09:42 AM, Doug Hellmann wrote:
Does "service VM" need to be a first-class thing? Akanda creates
them, using a service user. The VMs are tied to a "router" which
is the billable resource that the user understands and interacts with
through the API.
Frankly, I believe all of these
Excerpts from Curtis's message of 2017-06-19 18:56:25 -0600:
> On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote:
> > Trove has evolved rapidly over the past several years, since integration in
> > IceHouse when it only supported single instances of a few databases. Today
> > it supports a dozen
On 19/06/17 20:56, Curtis wrote:
I really think the
concept of "service VMs" should be a thing. I'm not sure where the
OpenStack community has landed on that, my fault for not paying close
attention, but we should be able to create VMs for a tenant that are
not managed by the tenant but that coul
On 20/06/17 12:56, Curtis wrote:
> On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote:
>> Trove has evolved rapidly over the past several years, since integration in
>> IceHouse when it only supported single instances of a few databases. Today
>> it supports a dozen databases including clusters
On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote:
> Trove has evolved rapidly over the past several years, since integration in
> IceHouse when it only supported single instances of a few databases. Today
> it supports a dozen databases including clusters and replication.
>
> The user survey [1
Amrith,
Some good thoughts in your email. I've replied to a few specific pieces
below. Overall I think it's a good start to a plan.
On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar
wrote:
> Trove has evolved rapidly over the past several years, since integration
> in IceHouse when it only supporte
ase consider this architecture.
Thanks,
Kevin
From: Amrith Kumar [amrith.ku...@gmail.com]
Sent: Sunday, June 18, 2017 4:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove
Trove has evol
Amrith Kumar wrote:
> [...]
> An important aspect of making this proposal work is that we seek to
> eliminate the effort (planning, and coding) involved in migrating
> existing Trove v1 deployments to the proposed Trove v2. Effectively,
> with work beginning on Trove v2 as proposed here, Trove v1 a
Trove has evolved rapidly over the past several years, since integration in
IceHouse when it only supported single instances of a few databases. Today
it supports a dozen databases including clusters and replication.
The user survey [1] indicates that while there is strong interest in the
project,
Ok everyone here is the link to join. Please only join if you plan to
participate as there are a limit on these calls
https://hangouts.google.com/call/ncgjbzal5p7ttelna3ovzqu
__
OpenStack Development Mailing List (not f
2017 8:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [trove] Trove reboot meeting
The time has come! I have opened the hangout, You can join now!
Please only join if you plan on participating in the discussion as there is a
limit on these
/dhxlygwb4vbvffgfjjaerg3geiu
-Original Message-
From: MCCASLAND, TREVOR
Sent: Monday, May 22, 2017 12:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Trove reboot meeting
*** Security Advisory: This Message Originated Outside
pment Mailing List (not for usage questions)'
Subject: Re: [openstack-dev] [trove] Trove meeting time update
Thanks for doing this Trevor, I am hoping that this patch merges soon so we can
do the new meeting time on Wednesday.
--
Amrith Kumar
amrith.ku...@gmail.com
> -Ori
On 2017-05-22 17:42:09 + (+), MCCASLAND, TREVOR wrote:
> Thanks Jeremy, that will work for our updated weekly meeting.
>
> To clear any confusion, this is a one-time project-scope meeting
> focused on hearing the needs of the new contributors we have as
> well as trove's current goals. It'
--Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org]
Sent: Monday, May 22, 2017 12:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Trove reboot meeting
On 2017-05-22 16:50:10 + (+), MCCASLAND, TREVOR wrote:
[...]
: [openstack-dev] [trove] Trove reboot meeting
Trevor,
1500 UTC is 1600 BST and 1700 CEST which is quite late for the French. Our
friends in Berlin may be up for it. I recommend 1500 BST which is 1400 UTC. Of
course, your suggestion works well for the US west coast.
Cheers,
Justin
On 22 May 2017 at 17
On 2017-05-22 16:50:10 + (+), MCCASLAND, TREVOR wrote:
[...]
> Sharing google calendar events can be a pain but it only gives us
> a notification for our calendars so.. I'm not going to bother with
> it that much. If you really want it on your calendar you can email
> me and I will add you
7; need to do this.
>
> -Original Message-
> From: MCCASLAND, TREVOR
> Sent: Friday, May 19, 2017 2:35 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [trove] Trove reboot m
y, May 19, 2017 2:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove] Trove reboot meeting
*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
As a
The Trove weekly meeting time has been changed from 1800UTC on Wednesdays to
1500UTC on Wednesdays[1]. Thanks to Trevor for following up on this action
item from the discussions we had in the summit in Boston.
This change has been made to accommodate some new participants to the
community from Eur
o: OpenStack Development Mailing List (not for usage questions) d...@lists.openstack.org>
> Subject: [openstack-dev] [trove] Trove meeting time update
>
> I have submitted a patch for updating the regular trove meeting time to 1500
> UTC. This was decided during the trove project update m
As a result of a large number of new contributors looking for direction from
our project, we would like to host a focused meeting on the project's scope.
Please let us know your availability for this one time meeting by using this
doodle poll[1]
We have brainstormed a few ideas for discussion
I have submitted a patch for updating the regular trove meeting time to 1500
UTC. This was decided during the trove project update meeting last week[1]
If you weren't able to make it and want to voice your opinion or If you feel
like a better time is more suitable, feel free to make a suggestion
I've not seen anything new on the agenda and I have a late scheduling
conflict today. Let's catch up on IRC if there is anything that needs
discussing.
--
Amrith Kumar
amrith.ku...@gmail.com
__
OpenStack Development Maili
There's nothing to discuss on the agenda today so I'm canceling the meeting
for today.
-amrith
--
Amrith Kumar
amrith.ku...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-
1 - 100 of 851 matches
Mail list logo