Hi all,
We want to kick off the next OpenStack bug smash and it targets Nov 30 - Dec 2
(Wed - Fri) at Shenzhen in China, which was voted in the last bug smash at
Hangzhou, for the next Ocata release.
The release schedule and Thanksgiving day are considered for the date.
Do any of you want to
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Anita, sorry about replying to you slowly. Because we are a committee from a
couple of companies, and need discussion, which causes slowness.
I am not the only decision maker. Thanks Anita;)
Regards.
--
Shane
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent:
; Liang, Maggie
Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
On Mon, Jun 13, 2016 at 08:06:50AM +, Wang, Shane wrote:
> Hi, OpenStackers,
>
> As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug
> Smash at Hangzhou, China.
> The 1st
; Liang, Maggie
Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
On Mon, Jun 13, 2016 at 08:06:50AM +, Wang, Shane wrote:
> Hi, OpenStackers,
>
> As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug
> Smash at Hangzhou, China.
> The 1st
, a best practice is to
publish a sponsorship prospectus online on a date known in advance with
sponsorships filled on a "first to sign" basis.
Regards,
Tom
On 13/06/16 16:06, Wang, Shane wrote:
> Hi, OpenStackers,
> As you know, Huawei, Intel and CESI are hosting the 4th Ch
: Zhuangzhen; anni@huawei.com; Liang, Maggie
Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
On Mon, Jun 13, 2016 at 08:06:50AM +, Wang, Shane wrote:
> Hi, OpenStackers,
>
> As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug
> Smash at Han
to join Hangzhou Bug Smash
Hi
I would, once again, love to attend.
If you find that other cores apply and you'd rather have a new face, I would be
very understanding of the situation.
Regards
--
Duncan Thomas
On 13 June 2016 at 11:06, Wang, Shane
<shane.w...@intel.com<mailto:shane.w...@int
Sorry I had a wrong person on the CC list, so resend.
Hi, OpenStackers,
As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug
Smash at Hangzhou, China.
The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd was
at Chengdu.
We are constructing the
Hi, OpenStackers,
As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug
Smash at Hangzhou, China.
The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd was
at Chengdu.
We are constructing the etherpad page for registration, and the date will be
Typo: view -> review:)
From: Wang, Shane
Sent: Saturday, March 05, 2016 2:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [bug-smash] Global OpenStack Bug Smash Mitaka
A reminder for the community, the bug smashes are going to start next Monday,
if you ca
A reminder for the community, the bug smashes are going to start next Monday,
if you can't join those 11 sites, you can do virtual bug smash remotely by
fixing the bugs in your offices.
Also, please help do remote view. Thanks.
Best Regards.
--
Shane
From: Wang, Shane [mailto:shane.w
-smash] Global OpenStack Bug Smash Mitaka
"Wang, Shane" <shane.w...@intel.com> wrote on 02/05/2016 04:42:21 AM:
> From: "Wang, Shane" <shane.w...@intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstac
page for the location [2] is
under construction. Hope to see some of you in Nuremberg!
[1] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
[2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-Nuremberg
--
Thanks,
Robert
On Friday 05 February 2016, 03:42:21 Wang, Shane
: Saturday, February 06, 2016 5:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
On 2016-02-05 03:42:21 + (+), Wang, Shane wrote:
> After discussing with TC members and other community guys,
Hi all,
After discussing with TC members and other community guys, we thought March 2-4
might not be a good timing for bug smash. So we decided to change the dates to
be March 7 - 9 (Monday - Wednesday) in R4.
Please join our efforts to fix bugs for OpenStack.
Thanks.
--
Shane
From: Wang
Hope somebody on the website infrastructure can help us. I have one
presentation which was filled into the form but not submitted.
Best Regards.
--
Shane
-Original Message-
From: Nick Chase [mailto:nch...@mirantis.com]
Sent: Monday, February 01, 2016 4:09 PM
To:
Yes, I was confused too. The time is yet up.
--
Shane
-Original Message-
From: Christian Berendt [mailto:christ...@berendt.io]
Sent: Sunday, January 31, 2016 11:43 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Call for papers already closed?
Hello.
I am a little
Save the Date:
Global OpenStack Bug Smash
Wednesday-Friday, March 2-4, 2016
RSVP by Friday, February 19
How can you help make the OpenStack Mitaka release stable and bug-free while
having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei,
CESI and others in a global bug
Hi Rosa,
I am one of the organizers of China Hackathons.
I think it is a good idea to host a Hackathon in Europe right after the
mid-cycle meetup. However, I suggest to allow more days instead of only 1 to
fix bugs, or you have to get well prepared, because fixing bugs is about
reproducing,
Open the mid-cycle one day ahead, feasible?
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Thursday, November 12, 2015 10:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] hackathon day
On Thu, Nov
Hey, how about driving a Hackathon on the same dates in 3 geos right before
release? Who are interested in?
Best Regards.
--
Shane
-Original Message-
From: Wang, Shane [mailto:shane.w...@intel.com]
Sent: Thursday, November 12, 2015 11:03 PM
To: Daniel P. Berrange; OpenStack Development
Yes, Anita. We are seeking the alternatives to fix it and hope the CIs can be
recovered very soon.
Also please allow me to explain a little bit, we shut down the service without
any email notification, but update the wiki
(https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI) only
AFAIK, TrustedFilter is using a sort of cache to cache the trusted state, which
is designed to solve the performance issue mentioned here.
My thoughts for deprecating it are:
#1. We already have customers here in China who are using that filter. How are
they going to do upgrade in the future?
Ditto, I am also interested in that area. We're implementing a framework to
monitor different metrics from Ceilometer, apply predefined policies from
administrators, and take actions if some conditions are met for resource
optimization purpose or SLA purpose.
Jay, is IBM PRS open source?
Hi Dan, are you going to cook a patch to expand the base class? Or we can do
that ourselves?
For the list, I also agree your dirty assumption.
--
Shane
-Original Message-
From: Dan Smith [mailto:d...@danplanet.com]
Sent: Friday, January 10, 2014 10:42 PM
To: Wang, Shane; OpenStack
Hi Dan,
There is a discussion in https://review.openstack.org/#/c/58199/ talking about
the change detection in objects.
If an object A contains another object or object list (called sub-object), any
change happened in the sub-object can't be detected by obj_what_changed() in
object A.
A
Lianhao Lu, Shuangtai Tian and I are also willing to join the team to
contribute because we are also changing scheduler, but it seems the team is
full. You can put us to the backup list.
Thanks.
--
Shane
-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net]
Sent:
Hi stackers,
From the design summit, Boris has a great idea to improve db performance but
needs more evaluation because of memcached.
For UBS, it seems we agree to go with the current solution and don't depend on
Boris's great idea.
Can someone help to review the ground work of UBS
Hi stackers,
From the design summit, Boris has a great idea to improve db performance but
needs more evaluation because of memcached.
For UBS, it seems we agree to go with the current solution and don't depend on
Boris's great idea.
Can someone help to review the ground work of UBS
Definitely, +1 ;-)
--
Shane
From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: Tuesday, August 27, 2013 11:40 PM
To: Daniel P. Berrange; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times
On Tue, Aug 27, 2013 at 11:04 AM, Daniel P.
Hi,
We submitted the patches for bp
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling 1+
month ago.
The first patch is to add a column to save metrics collected by plugins -
https://review.openstack.org/#/c/35759/.
Is there anyone who is interested in that, would it be
I prefer nova/compute/plugins/virt/libvirt, because I think a plugin might not
call libvirt or any virt driver.
By the way, can nova core or those who are interested in the bp review our
patch sets at
community
agreed that it would be discussed on the coming summit.
Best regards,
Boris Pavlovic
--
Mirantis Inc.
On Wed, Jul 31, 2013 at 9:36 AM, Wang, Shane
shane.w...@intel.commailto:shane.w...@intel.com wrote:
Hi,
I have a patchset ready for your review https://review.openstack.org/#/c/38802
Sandy Walsh wrote on 2013-07-19:
On 07/19/2013 09:47 AM, Day, Phil wrote:
-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: 19 July 2013 12:04
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics
Daniel raised a good point, I also agreed that is not a good architecture.
Nova can't touch any monitoring stuffs - I don't think that is good.
At least, Ceilometer can be a monitoring hub for external utilities.
On the other hand, for the options Lianhao raised.
Is a query on a DB and a json
Hi
I am looking at ceilometer DB code. I find there are 3 tables (UniqueName,
Event, Trait), and in Trait, the two columns name_id and event_id refer to
table UniqueName and table Event.
My question is why we need UniqueName and Event, because in both tables there
are no many other columns,
+1 for that.
If needed, some tools/languages could help to do XML transformation, regarding
different XML schemas.
I also agree with Hellmann that we shouldn't invent something new or a fixed
schema for that. XML is flexible for data exchange, we can leave those mapping
jobs to those XML
Very glad to see that, too. We also have some thoughts to look at the usage of
CPU resources (like cache) for each VM, and adjust to aggregate and bind VMs to
physical CPUs for QoS.
Look forward to seeing the initiatives proposed below to move forward.
Thanks.
--
Shane
-Original
39 matches
Mail list logo
