Yes, the usage of fanout topic by VNI is also another big improvement we
could do.
That will fit perfectly for the l2-pop mechanism driver.
Of course, that need a specific call on a start/re-sync to get initial
state. That actually done by the l2-pop MD if the uptime of an agent is
less than 'agent
On Sat, Jun 28, 2014 at 08:26:44AM -0500, Matt Riedemann wrote:
>
>
> On 6/27/2014 7:35 AM, Daniel P. Berrange wrote:
> >On Fri, Jun 27, 2014 at 07:40:51AM -0400, Sean Dague wrote:
> >>It's clear that lots of projects want 3rd Party CI information on
> >>patches. But it's also clear that 6 months
Howdy!
Paging other 3rd party CI operators...
I would like to run a simple and robust 3rd party CI. Simple as in a small
number of moving parts, robust as in unlikely to make mistakes due to
unexpected problems.
I'm imagining:
- 100 lines of shell for the implementation.
- Minimum of daemons.
I am trying to finish off https://review.openstack.org/#/c/90134 - percona
xtradb
cluster for debian based system.
I have read into this thread that I can error out on Redhat systems when trying
to
install percona and tell them to use mariadb instead, percona isn't support
here. Is
this corr
Hi stackers,
I found some problems about the current implement of
limit-volume-copy-bandwidth (this patch has been merged in last week.)
Firstly, assume that I configurate volume_copy_bps_limit=10M, If the path
is a block device, cgroup blkio can limit copy-bandwidth separately for ever
On 06/28/2014 10:49 PM, Mark McLoughlin wrote:
On Fri, 2014-06-27 at 17:02 +0100, Gordon Sim wrote:
A question about the new 'retry' option. The doc says:
By default, cast() and call() will block until the
message is successfully sent.
What does 'successfully sent' mean here?
Unc
Hi,
As time goes on, meters will be a huge list, and some meters whose
resources have been deleted may be useless for me, can I filter them out
from meter list?
Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.opensta
On 06/29/2014 09:39 AM, Joshua Hesketh wrote:
> On 6/28/14 10:40 AM, James E. Blair wrote:
>> An alternate approach would be to have third-party CI systems register
>> jobs with OpenStack's Zuul rather than using their own account. This
>> would mean only a single report of all jobs (upstream and
Hi,
To proceed with this, I have sent (presumably) appropriate change to
review: https://review.openstack.org/#/c/103516/
--
Best regards,
Oleg Gelbukh
On Fri, Jun 27, 2014 at 6:40 PM, Jay Pipes wrote:
> Sure, why not? :)
>
>
> On 06/27/2014 06:25 AM, Oleg Gelbukh wrote:
>
>> Hello,
>>
>> As
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> On 06/27/2014 04:04 PM, Ihar Hrachyshka wrote: On 26/06/14 22:38,
> Alexei Kornienko wrote:
Hello Jay,
Benchmark for oslo.messaging is really simple: You create a
client that sends messages infinitively and a server that
p
Hi,
This is a reminder that we’ll have a community meeting today at
#openstack-meeting at 16.00 UTC.
Review action items
Current status (quickly by team members)
Further plans
Open discussion
You can also find the agenda and the links to the previous meeting minutes and
logs at https://wiki.ope
Hi,
What would be your opinion on the question “Should we place any important
functionality into __init__.py files or just use it for package level
initialization and exporting variables from module level to a package level?”.
I personally would prefer not to keep there anything like class Engi
Renat,
As far as I can tell, it is de-facto standard to not place anything at all
to __init__.py across the majority of OpenStack projects.
--
Best regards,
Oleg Gelbukh
On Mon, Jun 30, 2014 at 3:50 PM, Renat Akhmerov
wrote:
> Hi,
>
> What would be your opinion on the question “Should we plac
Ok, Oleg, thanks!
> Jun 30, 2014, в 19:26, Oleg Gelbukh написал(а):
>
> Renat,
>
> As far as I can tell, it is de-facto standard to not place anything at all to
> __init__.py across the majority of OpenStack projects.
>
> --
> Best regards,
> Oleg Gelbukh
>
>
>> On Mon, Jun 30, 2014 at 3:50
Every time I crack open a nova logs in detail, at least 2 new olso
incubator log issues have been introduced.
The current ones is clearly someone is over exploding arrays, as we're
getting things like:
2014-06-29 13:36:41.403 19459 DEBUG nova.openstack.common.processutils
[-] Running cmd (subproce
Hi,
There is a patch for radvd https://review.openstack.org/#/c/102648/2 that you
can use in addition to the devstack patch. You want to make sure that ipv6 is
enabled and ra accepted with your VM’s image. Both patches are under
development.
To use dhcpv6, the current dhcp agent should be wor
On 06/29/2014 08:01 PM, Michael Still wrote:
Hi. The meeting this week would be on the 3rd of July, which I assume
means that many people will be out of the office. Do people think its
worth running the meeting or shall we give this week a miss?
I will be traveling during the meeting so I'm +1
On Jun 30, 2014 9:23 AM, "Andrew Laski" wrote:
>
>
> On 06/29/2014 08:01 PM, Michael Still wrote:
>>
>> Hi. The meeting this week would be on the 3rd of July, which I assume
>> means that many people will be out of the office. Do people think its
>> worth running the meeting or shall we give this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
in case you wonder why your neutron checkout fails recently with
'DuplicateOptError: duplicate option: fake_rabbit' error, this is
because neutron migrated to oslo.messaging recently, and old RPC layer
was removed from the tree. The problem is t
Hi All,
we have analyzed the nova-scheduler component (FilterScheduler) in our
Openstack installation used by some scientific teams.
In our scenario, the cloud resources need to be distributed among the
teams by considering the predefined share (e.g. quota) assigned to each
team, the portion
Hi,
It'd be nice to fix the fact that oslosphinx & hacking are
build-depending on each other. How can we fix this?
Thomas Goirand (zigo)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinf
On 06/27/2014 06:25 PM, Oleg Gelbukh wrote:
> Hello,
>
> As our commits consistently pass py33 tests for last month (although not
> so many changes were made), I propose to enable py33 job voting on
> stackforge/rubick repository.
>
> What do you think?
>
> --
> Best regards,
> Oleg Gelbukh
Hi,
I had an IRC discussion with jtomasek and rdopieralski recently regarding
Radomir's patch for converting to SCSS bootstrap.
https://review.openstack.org/#/c/90371/ We were trying to sort out how
soon this patch should merge. We'd like to discuss this at the team
meeting tomorrow, but I'm sharin
On Mon 30 Jun 2014 08:09:40 AM MDT, Douglas Fish wrote:
>
> I had an IRC discussion with jtomasek and rdopieralski recently regarding
> Radomir's patch for converting to SCSS bootstrap.
> https://review.openstack.org/#/c/90371/ We were trying to sort out how
> soon this patch should merge. We'd
On 30 June 2014 16:05, Eric Frizziero wrote:
> In more detail, some features of the FairshareScheduler are:
> a) It assigns dynamically the proper priority to every new user requests;
> b) The priority of the queued requests will be recalculated periodically
> using the fairshare algorithm. This
On 2014-06-30 22:11:30 +0800 (+0800), Thomas Goirand wrote:
> It'd be nice to fix the fact that oslosphinx & hacking are
> build-depending on each other. How can we fix this?
They're only build-depending on one another (in the Debian sense)
because you have made them to do so. Hacking does have a
On 06/30/2014 12:22 PM, Ihar Hrachyshka wrote:
Alexei Kornienko wrote:
Some performance tests may be introduced but they would be more
like functional tests since they require setup of actual
messaging server (rabbit, etc.).
Yes. I think we already have some. F.e.
tests/drivers/test_impl_qpid.
On 2014-06-30 22:14:53 +0800 (+0800), Thomas Goirand wrote:
[...]
> please also consider adding support for Python 3.4 at least,
This is in progress. Just last week we started running some CI jobs
on Ubuntu Trusty, which has Python 3.4 available in its main
archive. The plan is to add new gate-{na
Many thanks everyone for the feedback
Best regards,
Max Lobur,
OpenStack Developer, Mirantis, Inc.
Mobile: +38 (093) 665 14 28
Skype: max_lobur
38, Lenina ave. Kharkov, Ukraine
www.mirantis.com
www.mirantis.ru
On Mon, Jun 30, 2014 at 4:10 PM, Robert Li (baoli) wrote:
> Hi,
>
> There is a p
I noticed that there is no locale directory or setup.cfg entry for
babel, which surprises me. The v1_1 shell in python-novaclient has a
lot of messages marked for translation using the _() function but the v3
shell doesn't, presumably because someone figured out we don't translate
the client m
Joshua Hesketh writes:
> On 6/28/14 10:40 AM, James E. Blair wrote:
>> An alternate approach would be to have third-party CI systems register
>> jobs with OpenStack's Zuul rather than using their own account. This
>> would mean only a single report of all jobs (upstream and 3rd-party)
>> per-pat
On 06/30/2014 11:16 AM, Michael Kerrin wrote:
I am trying to finish off https://review.openstack.org/#/c/90134 -
percona xtradb cluster for debian based system.
I have read into this thread that I can error out on Redhat systems when
trying to install percona and tell them to use mariadb instead
It's possible that the only purpose of this discussion will be to fix my
thinking, but I still can't understand why we are so anxious to integrate a
patch that makes Horizon look funny. I expect the patch Radomir has our
for review will be quite stable. People should be able to contribute work
ba
Dan Smith wrote on 06/27/2014 12:33:48 PM:
>
> > What if 3rd Party CI didn't vote in Gerrit? What if it instead
> > published to some 3rd party test reporting site (a thing that
> > doesn't yet exist). Gerrit has the facility so that we could inject
> > the dashboard content for this in Gerrit in
Hi Gary,
Thanks for sending this out, comments inline.
On 29 June 2014 00:15, Gary Kotton wrote:
> Hi,
> At the moment there are a number of different BP’s that are proposed to
> enable different VMware network management solutions. The following specs
> are in review:
>
>1. VMware NSX-vS
Sean Dague wrote on 06/30/2014 06:03:50 AM:
> From:
>
> Sean Dague
>
> To:
>
> "OpenStack Development Mailing List (not for usage questions)"
> ,
>
> Date:
>
> 06/30/2014 06:09 AM
>
> Subject:
>
> Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
>
> On 06/29/2014 09:39 AM, Joshua Hesketh wrote
On Mon, Jun 30, 2014 at 10:18 AM, Armando M. wrote:
> Hi Gary,
>
> Thanks for sending this out, comments inline.
>
Indeed, thanks Gary!
> On 29 June 2014 00:15, Gary Kotton wrote:
>>
>> Hi,
>> At the moment there are a number of different BP’s that are proposed to
>> enable different VMware netw
On 6/30/2014 8:30 AM, Joe Gordon wrote:
On Jun 30, 2014 9:23 AM, "Andrew Laski" mailto:andrew.la...@rackspace.com>> wrote:
>
>
> On 06/29/2014 08:01 PM, Michael Still wrote:
>>
>> Hi. The meeting this week would be on the 3rd of July, which I assume
>> means that many people will be out
On Mon, Jun 30, 2014 at 3:19 AM, Luke Gorrie wrote:
> Howdy!
>
> Paging other 3rd party CI operators...
>
> I would like to run a simple and robust 3rd party CI. Simple as in a small
> number of moving parts, robust as in unlikely to make mistakes due to
> unexpected problems.
>
> I'm imagining:
>
2014-06-30 19:17 GMT+04:00 Kurt Taylor :
> Dan Smith wrote on 06/27/2014 12:33:48 PM:
> > If it really does show up right in Gerrit as if it were integrated,
> > then that would be fine with me. I think the biggest problem we have
> > right now is that a lot of the CI systems are very inconsisten
On 06/30/2014 11:41 AM, Ilya Shakhat wrote:
> 2014-06-30 19:17 GMT+04:00 Kurt Taylor :
>
>> Dan Smith wrote on 06/27/2014 12:33:48 PM:
>>> If it really does show up right in Gerrit as if it were integrated,
>>> then that would be fine with me. I think the biggest problem we have
>>> right now is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> There is a similar old bug for that, with a good suggestion for how
> it could possibly be done:
>
> https://bugs.launchpad.net/openstack-ci/+bug/1251758
This isn't what I'm talking about. What we need is, for each new
patchset on a given change, a
forwarding I18n Team.
--
About.me
부터: Matt Riedemann mrie...@linux.vnet.ibm.com
답장: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
날짜: 2014년 7월 1일 at 오전 12:02:41
에게: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists
On 30 June 2014 17:34, Kyle Mestery wrote:
> It would be great to get you to join the 3rd Party meeting [1] in
> #openstack-meeting at 1800UTC to discuss this. Can you make it today
> Luke?
>
Yes, I'll be there.
Currently I'm looking into "the simplest 3rd party CI that could possibly
work" whi
Thanks everyone for joining us!
As usually,
Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-06-30-16.01.html
Full log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-06-30-16.01.log.html
The next meeting will be on July 7th.
Renat Akhmerov
I have out for review 103536 to add this version to global requirements, so
that Neutron has an oslo fix (review 102909) for encoding failure, which
affects some gate runs. This review for global requirements is failing
requirements check
(http://logs.openstack.org/36/103536/1/check/check-requi
Hi all -
For those who don't know me, I'm Mike Bayer, creator/maintainer of
SQLAlchemy, Alembic migrations and Dogpile caching. In the past month
I've become a full time Openstack developer working for Red Hat, given
the task of carrying Openstack's database integration story forward.
To that
On 25/06/14 14:32 -0400, Jordan OMara wrote:
On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote:
Is $179/day the expected rate?
Thanks,
Chuck
Yes, that's the best rate available from both of the downtown
(walkable) hotels.
Just an update that we only have a few rooms
woot!
From: Mike Bayer [mba...@redhat.com]
Sent: Monday, June 30, 2014 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [oslo] Openstack and SQLAlchemy
Hi all -
For those who don't know me, I'm Mike Bayer
Not sure if these are “minimalist” but at least they setup automagically, so
you don’t need to do it from scratch:
You can check out these repos which automate the 3rd party ci setup:
Jay Pipe’s solution:
https://github.com/jaypipes/os-ext-testing
https://github.com/jaypipes/os-ext-testing-data
On Jun 29, 2014, at 17:01, Michael Still wrote:
> Hi. The meeting this week would be on the 3rd of July, which I assume
> means that many people will be out of the office. Do people think its
> worth running the meeting or shall we give this week a miss?
July 3 is a company holiday where I am, s
On 30 June 2014 19:37, Asselin, Ramy wrote:
> Not sure if these are “minimalist” but at least they setup
> automagically, so you don’t need to do it from scratch:
>
I'm aiming to do exactly the opposite of this i.e. no automagic.
My experience has been that the really heavy-duty CI setups are
I have a really early sketch of this project on Github now.
shellci - OpenStack 3rd party CI in 100 lines of shell
https://github.com/SnabbCo/shellci
This is not finished yet but I'll try to use it for the new Neutron mech
driver that I want to contribute to Juno.
Ideas and encouragement welcome
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cinder SSH Pool will auto-accept SSH host signatures by default
- ---
### Summary###
In OpenStack releases prior to Juno, the SSH connection pool used by
Cinder drivers to control SAN hosts will silently auto-accept SSH host
fingerprints. This potenti
Excerpts from Michael Kerrin's message of 2014-06-30 02:16:07 -0700:
> I am trying to finish off https://review.openstack.org/#/c/90134 - percona
> xtradb
> cluster for debian based system.
>
> I have read into this thread that I can error out on Redhat systems when
> trying to
> install perco
Hello all,
The subject of 3rd party CI voting responses came up in the 3rd-party IRC
meeting today.[1] We would like to get feedback from the larger dev
community on what acceptable response times are for third party CI systems.
As a maintainer of a small CI system that tends to get backed up dur
On 06/29/2014 07:59 PM, Anita Kuno wrote:
> On 06/29/2014 07:43 PM, Anita Kuno wrote:
>> On 06/29/2014 03:25 PM, Ilya Shakhat wrote:
>>> Hi!
>>>
>>> During last couple weeks there is an increasing demand on tracking
>>> 3rd-party CI statuses. We at Stackalytics decided to be in trend and (with
>>>
The current design for ovs-neutron-agent is that it will wipe out all
flows configured on the system when it starts up, recreating them for
each neutron port it's aware of. This has a not-so-desirable side
effects that there's a temporary hiccup in network connectivity for the
VMs on the host.
Hi folks:
I wanted to give an update to people following the third-party CI
conversation for Neutron. I sent an email out with a status update in
June [1]. In that email, I had indicated that in-tree plugins and
drivers needed to have functioning CI running by Juno-2. That is still
the case, and I
On Mon, Jun 30, 2014 at 2:11 PM, Paul Ward wrote:
> The current design for ovs-neutron-agent is that it will wipe out all flows
> configured on the system when it starts up, recreating them for each neutron
> port it's aware of. This has a not-so-desirable side effects that there's a
> temporary
On 30 June 2014 21:08, Anita Kuno wrote:
> I am disappointed to realize that Ilya (or stackalytics, I don't know
> where this is coming from) is unwilling to cease making up definitions
> of success for third party ci systems to allow the openstack community
> to arrive at its own definition.
>
On 06/30/2014 03:27 PM, Luke Gorrie wrote:
> On 30 June 2014 21:08, Anita Kuno wrote:
>
>> I am disappointed to realize that Ilya (or stackalytics, I don't know
>> where this is coming from) is unwilling to cease making up definitions
>> of success for third party ci systems to allow the openstac
Hello,
> My understanding is that your analysis is mostly based on running a
> profiler against the code. Network operations can be bottlenecked in
> other places.
>
> You compare 'simple script using kombu' with 'script using
> oslo.messaging'. You don't compare script using oslo.messaging befor
Indeed a blueprint has been filed (on Launchpad, not neutron-specs) on this
already[0], but there has been no work on this as far as I can tell. I think it
would be worthwhile contribution.
Amir
[0] https://blueprints.launchpad.net/neutron/+spec/neutron-agent-soft-restart
_
Well, Luke, this is collaborative effort by everybody. By having these CI
systems in place ensures that one person's code does not break other
person's code and vice versa. Therefore, having these CI systems
operational and voting 24x7 is a critical step in achieving this goal.
However, the detail
We approved
https://github.com/openstack/qa-specs/blob/master/specs/client-checks-success.rst
which recommends that checking of correct success codes be moved to the
tempest clients. This has been done for the image tests but not others
yet. But new client/test code coming in should definitely
Hi Stackers,
Some recent ML threads [1] and a hot IRC meeting today [2] brought up
some legitimate questions around how a newly-proposed Stackalytics
report page for Neutron External CI systems [2] represented the results
of an external CI system as "successful" or not.
First, I want to say
The latest revisions of the logging guidelines is available in the
nova-specs repo - https://review.openstack.org/#/c/91446/
I tried to integrate the comments from the last go around into that. I
do think we're at a state where if we believe this is a set of first
pass guidelines that we're good w
Sorry, accidentally hit the wrong key and message went out.
Was making a mention about the definition of Success. I thought the debate
in the meeting was very productive - when a CI posts a +1 that is success,
and when a CI posts a -1 (or no vote with comment) is also a success - as
this refle
Hi Jay,
Couple of points.
I support the fact that we need to define what is "success" is.
I believe that the metrics that should be used are "Voted +1" and
"Skipped".
But to certain valid case, I would say that the "Voted -1" is really
mostly a metric of bad health of a CI.
Most of the -1 are du
Hi all,
Specs are interesting idea, that may be really useful, when you need to
discuss large topics:
1) work on API
2) Large refactoring
3) Large features
4) Performance, scale, ha, security issues that requires big changes
And I really dislike idea of adding spec for every patch. Especially whe
I'm far from an oslo.messaging expert, but a few general thoughts below.
On 06/30/2014 02:34 PM, Alexei Kornienko wrote:
> Hello,
>
>
>> My understanding is that your analysis is mostly based on running a
>> profiler against the code. Network operations can be bottlenecked in
>> other places.
>>
On Mon, 2014-06-30 at 16:52 +, Paul Michali (pcm) wrote:
> I have out for review 103536 to add this version to global
> requirements, so that Neutron has an oslo fix (review 102909) for
> encoding failure, which affects some gate runs. This review for global
> requirements is failing requiremen
Thanks boris for starting this topic,
There is a balance here that needs to be worked out and I've seen specs start
to turn into requirements for every single patch (even if the patch is pretty
small). I hope we can rework the 'balance in the force' to avoid being so
strict that every little th
On Mon, Jun 30, 2014 at 3:17 PM, Mark McLoughlin wrote:
> On Mon, 2014-06-30 at 12:04 -0600, John Griffith wrote:
> > Hey Everyone,
> >
> >
> > So I sent a note out yesterday asking about config changes brought in
> > to Icehouse due to the OSLO Messaging update that went out over the
> > week-en
Excerpts from Boris Pavlovic's message of 2014-06-30 14:11:08 -0700:
> Hi all,
>
> Specs are interesting idea, that may be really useful, when you need to
> discuss large topics:
> 1) work on API
> 2) Large refactoring
> 3) Large features
> 4) Performance, scale, ha, security issues that requires
Hi Eric,
definitely...
In my view a "FairShareScheduler" could be a very interesting option for
private clouds that support scientific communities. Basically this is the
model used by batch systems in order to fully use the available resources.
I'm very curious about the work that you are doing.
On Mon, 2014-06-30 at 15:35 -0600, John Griffith wrote:
>
>
>
>
> On Mon, Jun 30, 2014 at 3:17 PM, Mark McLoughlin
> wrote:
> On Mon, 2014-06-30 at 12:04 -0600, John Griffith wrote:
> > Hey Everyone,
> >
> >
> > So I sent a note out yesterday asking abou
Hi folks,
The DVR team is working really hard to complete this important task for
Juno and Neutron.
In order to help see this feature in action, a video has been made
available and link can be found in [2].
There is still some work to do, however I wanted to remind you that all of
the relevant i
Howdy folks,
Given the feedback from people on this list last week to my suggestion
about holding elections for PTL and core reviewers for the Octavia project,
it's clear that since we've only recently been added as a stackforge
project, we don't have any code or review history on which people can
Hi all!
We're roughly at the midway point between summit and release, and I
feel that's a good time to take a look at our progress compared to the
goals we set out at the design summit. To that end, I re-opened my
summit notes about what features we had prioritized in Atlanta, and
engaged many the
When you create a bug against a project (in our case, fuel) in
Launchpad, it is always initially targeted at the default release
series (currently, 5.1.x). On the bug summary, that isn't explicitly
stated and shows as being targeted to the project in general (Fuel for
OpenStack). As you add more re
Ok, let's skip the meeting this week so people can have a break.
Cheers,
Michael
On Tue, Jul 1, 2014 at 3:45 AM, melanie witt wrote:
> On Jun 29, 2014, at 17:01, Michael Still wrote:
>
>> Hi. The meeting this week would be on the 3rd of July, which I assume
>> means that many people will be out
On 06/30/2014 04:22 PM, Jay Pipes wrote:
> Hi Stackers,
>
> Some recent ML threads [1] and a hot IRC meeting today [2] brought up
> some legitimate questions around how a newly-proposed Stackalytics
> report page for Neutron External CI systems [2] represented the results
> of an external CI syste
Eric-
We have a weekly scheduler sub-group (code name gantt) IRC meeting at 1500 UTC
on Tuesdays. This would be an excellent topic to bring up at one of those
meetings as a lot of people with interest in the scheduler will be there. It's
a little short notice for tomorrow but do you think you
Greetings all stackers,
I propose that we add Pranesh Pandurangan[1] to the taskflow-core team[2].
Pranesh has been actively contributing to taskflow for a while now, both
in helping develop code and helping with the review load. He has provided
quality reviews and is doing an awesome job with th
anyone knows this?
2014-6-30 PM6:35于 "Ke Xia" 写道：
> Hi,
>
> As time goes on, meters will be a huge list, and some meters whose
> resources have been deleted may be useless for me, can I filter them out
> from meter list?
>
> Thanks
>
___
OpenStack-dev ma
On 06/30/2014 07:08 PM, Anita Kuno wrote:
On 06/30/2014 04:22 PM, Jay Pipes wrote:
Hi Stackers,
Some recent ML threads [1] and a hot IRC meeting today [2] brought up
some legitimate questions around how a newly-proposed Stackalytics
report page for Neutron External CI systems [2] represented th
+1
Thanks
Changbin
On Mon, Jun 30, 2014 at 8:05 PM, Joshua Harlow
wrote:
> Greetings all stackers,
>
> I propose that we add Pranesh Pandurangan[1] to the taskflow-core
> team[2].
>
> Pranesh has been actively contributing to taskflow for a while now, both
> in helping develop code and he
Hi,
I will be on PTO from Tuesday, and come back to office on July 9th Wednesday.
Therefore, I won’t be present in the next two SR-IOV weekly meetings. Regarding
the sr-iov development status, I finally fixed all the failures in the existing
unit tests. Rob and I are still working on adding new
1) Forklift (tasks & status)
2) Fair Share scheduler (just a heads up)
3) Opens
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://li
On 01.07.2014 04:05, Joshua Harlow wrote:
> Greetings all stackers,
>
> I propose that we add Pranesh Pandurangan[1] to the taskflow-core team[2].
>
> Pranesh has been actively contributing to taskflow for a while now, both
> in helping develop code and helping with the review load. He has provid
Eric,
Thanks for sharing your work, it looks like an interesting development.
I was wondering how the Keystone token expiry is handled since the tokens
generally have a 1 day validity. If the request is scheduling for more than one
day, it would no longer have a valid token. We have similar sce
93 matches
Mail list logo
