On 21/11/14 14:13 -0500, Doug Hellmann wrote:
On Nov 21, 2014, at 1:43 PM, Flavio Percoco fla...@redhat.com wrote:
On 21/11/14 12:07 -0500, Doug Hellmann wrote:
We have a bit of a backlog in the Oslo review queue. Before we add a bunch of
new reviews for Kilo work, I’d like to see if we can
Hi all,
By reading the tempest documentation page [1] a user can run tempest
tests by using whether testr or run_tempest.sh or tox.
What is the best practice?
run_tempest.sh has several options (e.g. ./run_tempest.sh -h) and it is
my preferred way, currently.
Any thought?
BR,
Angelo
[1]
Sorry for my previous message with wrong subject
Hi all,
By reading the tempest documentation page [1] a user can run tempest
tests by using whether testr or run_tempest.sh or tox.
What is the best practice?
run_tempest.sh has several options (e.g. ./run_tempest.sh -h) and it is
my preferred
Hi again,
I'd like to share some results of the bug day we've conducted on 2014-11-21.
Stats:
- 73 New bugs
https://bugs.launchpad.net/neutron/+bugs?search=Searchfield.status=New
- 795 Open bugs https://bugs.launchpad.net/neutron/+bugs
- 285 In-progress bugs
I proposed monasca-agent in a previous mail in this thread.
P.
On 11/21/2014 04:48 PM, Fox, Kevin M wrote:
How about this?
https://wiki.openstack.org/wiki/Monasca
Kevin *
*
*From:* Dmitriy Shulyak
*Sent:* Friday,
Hello All,
Current implementation of plugins in Fuel unpacks plugin tarball
into /var/www/nailgun/plugins/.
If we implement deployment part of plugin using puppet there is a setting
puppet_modules:
This setting should specify path to modules folder. As soon as main
deployment part of plugin is
Hi,
monasca looks overcomplicated for the purposes we need. Also it requires
Kafka which is Java based transport protocol.
I am proposing Sensu. It's architecture is tiny and elegant. Also it uses
rabbitmq as transport so we won't need to introduce new protocol.
--
Best regards,
Sergii
On Fri, Nov 21, 2014 at 01:52:50PM -0500, Matthew Treinish wrote:
On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
Hey,
I am not a Nova developer but I still have an opinion.
Using boolean assertions
I like what you propose. We should use and enforce the assert* that
On Fri, Nov 21, 2014 at 05:23:28PM -0500, Matthew Treinish wrote:
On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote:
On 11/21/2014 01:52 PM, Matthew Treinish wrote:
On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
Hey,
I am not a Nova developer but I still have
On Fri, Nov 21, 2014 at 10:30:59AM -0800, Joe Gordon wrote:
On Fri, Nov 21, 2014 at 8:57 AM, Sahid Orentino Ferdjaoui
sahid.ferdja...@redhat.com wrote:
On Thu, Nov 20, 2014 at 02:00:11PM -0800, Joe Gordon wrote:
On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui
Hi,
according to [1] you should be able to use:
puppet_modules: puppet/:/etc/puppet/modules/
This is valid string yaml parameter that should be parsed just fine.
[1]
https://github.com/stackforge/fuel-web/blob/master/tasklib/tasklib/actions/puppet.py#L61-L62
Regards
--
Alex
On Mon, Nov 24,
Unfortunately this does not work
cat tasks.yaml
# This tasks will be applied on controller nodes,
# here you can also specify several roles, for example
# ['cinder', 'compute'] will be applied only on
# cinder and compute nodes
- role: ['controller']
stage: post_deployment
type: puppet
Guys,
task like
- role: ['controller']
stage: post_deployment
type: puppet
parameters:
puppet_manifest: puppet/site.pp
puppet_modules: puppet/modules/
timeout: 360
works fine for me, so I believe your task should looks like
cat tasks.yaml
# This tasks will be applied on controller nodes,
# here
IMO, we should get a bunch of snapshots and decide which compression to use
according to the results of an experiment. XZ compression takes much
longer, so you will need to use parallel xz compression utility.
On Fri, Nov 21, 2014 at 9:09 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:
On
I did this exercise over many iterations during Docker container
packing and found that as long as the data is under 1gb, it's going to
compress really well with xz. Over 1gb and lrzip looks more attractive
(but only on high memory systems). In reality, we're looking at log
footprints from
I tried to reproduce this behavior with tasks.yaml:
# Deployment is required for controllers
- role: ['controller']
stage: post_deployment
type: puppet
parameters:
puppet_manifest: site.pp
puppet_modules: puppet/:/etc/puppet/modules
timeout: 360
And actually plugin was built
On 24 Nov 2014, at 12:25, Matthew Mosesohn mmoses...@mirantis.com wrote:
I did this exercise over many iterations during Docker container
packing and found that as long as the data is under 1gb, it's going to
compress really well with xz. Over 1gb and lrzip looks more attractive
(but only on
That was my fault. I did not expect that timeout parameter is a mandatory
requirement for task. Every thing works perfectly fine.
Thanks for the help.
On Mon, Nov 24, 2014 at 3:05 PM, Tatyana Leontovich
tleontov...@mirantis.com wrote:
Guys,
task like
- role: ['controller']
stage:
Mattherw, Dmitry
I would suggest to use:
1) multi-threaded utilities
2) use xz for small snapshots (1gb) and lrzip for bigger snapshots
On Mon, Nov 24, 2014 at 2:25 PM, Matthew Mosesohn mmoses...@mirantis.com
wrote:
I did this exercise over many iterations during Docker container
packing and
guys, there is already pxz utility in ubuntu repos. let's test it
On Mon, Nov 24, 2014 at 2:32 PM, Bartłomiej Piotrowski
bpiotrow...@mirantis.com wrote:
On 24 Nov 2014, at 12:25, Matthew Mosesohn mmoses...@mirantis.com wrote:
I did this exercise over many iterations during Docker container
I did not expect that timeout parameter is a mandatory requirement for
task
UX is obviously has to be improved here. Can we make a clear error, if
there is no required parameter, instead of throwing unclear exception?
On Mon, Nov 24, 2014 at 2:34 PM, Dmitry Ukov du...@mirantis.com wrote:
That
From: Eoghan Glynn [egl...@redhat.com] Friday, November 21, 2014 11:03 AM
Some problems / options:
a. Unlike Python, there is no simple pip install for text files. No
version control per se. Basically whatever we pull from the repo. The
problem with a git clone is we need to tweak config
Hi Andrew,
Comments inline.
Also could you please provide a link on OpenStack upgrade feature?
It's not clear why do you need it as a plugin and how you are going
to deliver this feature.
On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward xar...@gmail.com wrote:
So as part of the pumphouse
Hi,
As you know we can use Ceph as ephemeral storage in nova. But we have some
problems with its integration. First of all, total storage of compute nodes
is calculated incorrectly. (more details here
https://bugs.launchpad.net/nova/+bug/1387812). I want to fix this problem.
Now size of total
Hi Dmitry,
Our current validation implementation is based on jsonschema,
we will figure out how to hack/configure it to provide more human
readable message
Thanks,
On Mon, Nov 24, 2014 at 2:34 PM, Dmitry Ukov du...@mirantis.com wrote:
That was my fault. I did not expect that timeout parameter
OK, since there was no disagreement I pushed the changes to:
https://wiki.openstack.org/wiki/StableBranch
We'll get started setting up project-specific stable-maint teams ASAP.
Cheers,
Thierry Carrez wrote:
TL;DR:
Every project should designate a Stable branch liaison.
Hi everyone,
Last
Having XML payloads was never a universal part of OpenStack services.
During the Icehouse release the TC declared that being an OpenStack
service requires having a JSON REST API. Projects could do what they
wanted beyond that. Lots of them deprecated and have been removing the
XML cruft since
Hello,
Thanks to the work of Dean and others we have a pretty solid plugins/extras
support in Devstack. People can add new features in devstack within just a
single file and that add a whole new feature or driver to devstack.
It seems that there is quite a bit of people who wants to have those
On 11/24/2014 08:56 AM, Sean Dague wrote:
Having XML payloads was never a universal part of OpenStack services.
During the Icehouse release the TC declared that being an OpenStack
service requires having a JSON REST API. Projects could do what they
wanted beyond that. Lots of them deprecated and
Hi,
I cannot comment on the best practice.
But I can point to you a few more methods and links.
1. https://dague.net//presentations/tempest-101/#/
2.
http://www.slideshare.net/kamesh001/open-stack-qa-and-tempest?next_slideshow=1
3.
Angelo,
One more way to run Tempest is to run it via Rally.
Rally will take care about installation, generating tempest.conf, running
tempest, parsing storing output results.
Here is manual:
https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/
As a bonus you'll get
On 11/23/2014 06:13 PM, Robert Collins wrote:
On WSGI - if we're in an asyncio world, I don't think WSGI has any
relevance today - it has no async programming model. While is has
incremental apis and supports generators, thats not close enough to
the same thing: so we're going to have to port
Hi,
As most of you surely know the proposal for micro versioning in Nova [1]
has been approved for Kilo.
I am sure you are aware that a similar proposal has bee discussed for
Neutron at the design summit.
Considering the direction taken by nova, and the fact that neutron
extensions are becoming
On 11/24/2014 08:56 AM, Chmouel Boudjnah wrote:
Hello,
Thanks to the work of Dean and others we have a pretty solid
plugins/extras support in Devstack. People can add new features in
devstack within just a single file and that add a whole new feature or
driver to devstack.
It seems that
On 24 Nov 2014, at 11:09, Sergii Golovatiuk sgolovat...@mirantis.com wrote:
Hi,
monasca looks overcomplicated for the purposes we need. Also it requires
Kafka which is Java based transport protocol.
I am proposing Sensu. It's architecture is tiny and elegant. Also it uses
rabbitmq as
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - incorrect failure messages have cost me more time
than I should admit to. I don't see any reason not to try to
Matthew Gilliard said on Mon, Nov 24, 2014 at 02:50:08PM +:
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - I don't see any reason not to try to
Great progress! Thanks for this huge effort.
Edgar
From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, November 24, 2014 at 1:52 AM
To:
On 11/17/14 10:27 PM, Duncan Thomas wrote:
Is the new driver drop-in compatible with the old one? IF not, can
existing systems be upgraded to the new driver via some manual steps, or
is it basically a completely new driver with similar functionality?
The driver in san/solaris.py focuses
On Mon, Nov 24, 2014 at 3:32 PM, Sean Dague s...@dague.net wrote:
We should also make this something which is gate friendly. I think the
idea had been that if projects included a /devstack/ directory in them,
when assembling devstack gate, that would be automatically dropped into
devstack's
On 11/24/2014 10:17 AM, Chmouel Boudjnah wrote:
On Mon, Nov 24, 2014 at 3:32 PM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
We should also make this something which is gate friendly. I think the
idea had been that if projects included a /devstack/ directory in them,
Rob Basham
Cloud Systems Software Architecture
971-344-1999
Tomasz Napierala tnapier...@mirantis.com wrote on 11/24/2014 06:42:39
AM:
From: Tomasz Napierala tnapier...@mirantis.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:
On Nov 23, 2014, at 9:24 PM, Donald Stufft don...@stufft.io wrote:
There’s a long history of implicit context switches causing buggy software
that breaks. As far as I can tell the only downsides to explicit context
switches that don’t stem from an inferior interpreter seem to be “some
On Nov 24, 2014, at 9:23 AM, Adam Young ayo...@redhat.com wrote:
For pieces such as the Nova compute that talk almost exclusively on the
Queue, we should work to remove Monkey patching and use a clear programming
model. If we can do that within the context of Eventlet, great. If we
And it all started out with simple free disk space monitoring :)
I created a document
https://etherpad.openstack.org/p/fuel-master-monitoring
Let's write what exactly we want to monitor and what actions to take.
Then it would be easier to decide which system we want.
P.
On 11/24/2014 04:32
This is a reminder about our team meeting scheduled for today 16.00 UTC.
Agenda:
- Review action items
- Paris Summit results
- Current status (progress, issues, roadblocks, further plans)
- Release 0.2 progress
- Open discussion
--
Best Regards,
Nikolay
Fuelers
I am writing to you to suggest adding prefixes for Fuel subprojects/ as it
becomes more and more difficult to read all the emails in mailing lists.
Adding these prefixes should significantly improve ability of our engineers
to filter out emails they are not interested in, e.g. UI
Le 24/11/2014 04:20, Richard Jones a écrit :
Thanks everyone, I've closed the poll. I'm sorry to say that there's no
combination of two timeslots which allows everyone to attend a meeting.
Of the 25 respondents, the best we can do is cater for 24 of you.
Optimising for the maximum number
Thanks for joining us today,
Here are the links to the meeting minutes and full log:
- Minutes -
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-24-16.00.html
- Full log -
*http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-24-16.00.log.html
On 11/24/2014 11:01 AM, Vladimir Kuklin wrote:
Fuelers
I am writing to you to suggest adding prefixes for Fuel subprojects/ as
it becomes more and more difficult to read all the emails in mailing
lists. Adding these prefixes should significantly improve ability of our
engineers to filter out
On 11/24/2014 10:43 AM, Mike Bayer wrote:
On Nov 24, 2014, at 9:23 AM, Adam Young ayo...@redhat.com wrote:
For pieces such as the Nova compute that talk almost exclusively on
the Queue, we should work to remove Monkey patching and use a clear
programming model. If we can do that within the
[Fuel][Library] for compatibility with other projects. Let's negotiate the
list of prefixes and populate them on our wiki so that everyone can
configure his filters.
On Mon, Nov 24, 2014 at 7:26 PM, Jay Pipes jaypi...@gmail.com wrote:
On 11/24/2014 11:01 AM, Vladimir Kuklin wrote:
Fuelers
I
Hello,
On Fri, Nov 21, 2014 at 10:10 PM, Mike Bayer mba...@redhat.com wrote:
1. read about the new features, particularly the branch support, and
please let me know of any red flags/concerns you might have over the coming
implementation, at
On 11/24/2014 12:04 PM, Vladimir Kuklin wrote:
[Fuel][Library] for compatibility with other projects. Let's negotiate
the list of prefixes and populate them on our wiki so that everyone can
configure his filters.
++
-jay
___
OpenStack-dev mailing
We are in the process of removing XML support from Keystone [1] and have
provided
configuration options to Tempest for testing XML in older releases [2].
However, the
identity client is still tightly coupled to XML test cases. We can either
fix the 309 test cases
that use the XML identity client
On Nov 24, 2014, at 11:30 AM, Jay Pipes jaypi...@gmail.com wrote:
On 11/24/2014 10:43 AM, Mike Bayer wrote:
On Nov 24, 2014, at 9:23 AM, Adam Young ayo...@redhat.com wrote:
For pieces such as the Nova compute that talk almost exclusively on
the Queue, we should work to remove Monkey patching
On 11/24/2014 08:50 AM, Matthew Gilliard wrote:
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - incorrect failure messages have cost me more time
than I
After the Oslo meeting today, most of the folks preparing releases met
separately and decided to wait to create any new releases until the stable
branches are ready. We need devstack to install Oslo libs from packages
(merged) and to cap the Oslo requirements. Sean is going to raise the latter
On 11/24/2014 12:36 PM, Lance Bragstad wrote:
We are in the process of removing XML support from Keystone [1] and have
provided
configuration options to Tempest for testing XML in older releases [2].
However, the
identity client is still tightly coupled to XML test cases. We can either
fix
The pylint test job has been broken for weeks, no one seemed to care.
While waiting for other tests to return today I looked into it and
figured out the fix.
However, because of nova objects pylint is progressively less and less
useful. So the fact that no one else looked at it means that people
On 11/24/2014 10:14 AM, Drew Fisher wrote:
On 11/17/14 10:27 PM, Duncan Thomas wrote:
Is the new driver drop-in compatible with the old one? IF not, can
existing systems be upgraded to the new driver via some manual steps, or
is it basically a completely new driver with similar
+1 to cleanup.
-- dims
On Mon, Nov 24, 2014 at 12:50 PM, Monty Taylor mord...@inaugust.com wrote:
On 11/24/2014 12:36 PM, Lance Bragstad wrote:
We are in the process of removing XML support from Keystone [1] and have
provided
configuration options to Tempest for testing XML in older releases
On Nov 24, 2014, at 12:40 PM, Doug Hellmann d...@doughellmann.com wrote:
This is a good point. I’m not sure we can say “we’ll only use
explicit/implicit async in certain cases because most of our apps actually
mix the cases. We have WSGI apps that send RPC messages and we have other
However, because of nova objects pylint is progressively less and less
useful. So the fact that no one else looked at it means that people
didn't seem to care that it was provably broken. I think it's better
that we just delete the jobs and save a node on every nova patch instead.
Agreed.
On 11/24/2014 09:40 AM, Ben Nemec wrote:
On 11/24/2014 08:50 AM, Matthew Gilliard wrote:
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - incorrect failure
On Mon, Nov 24, 2014 at 9:52 AM, Sean Dague s...@dague.net wrote:
The pylint test job has been broken for weeks, no one seemed to care.
While waiting for other tests to return today I looked into it and
figured out the fix.
However, because of nova objects pylint is progressively less and
Hi,
In a multi-node setup with multiple Compute nodes, is there a way to control
where a VM will reside when launching a VM?
E.g. I would like to have VM-1 at Compute-1, VM-2 at Compute-2, etc…
Thanks,
Danny
___
OpenStack-dev mailing list
On 11/24/2014 01:02 PM, pcrews wrote:
On 11/24/2014 09:40 AM, Ben Nemec wrote:
On 11/24/2014 08:50 AM, Matthew Gilliard wrote:
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
Hello all,
at our last Sahara IRC meeting we started discussing whether or not to add
a global requirement for cm_api.py https://review.openstack.org/#/c/130153/
One issue (but not the only issue) is that cm_api is not packaged for Fedora,
Centos, or Ubuntu currently. The global requirements
On 11/13/2014 01:12 AM, Robert Collins wrote:
On 11 November 2014 13:30, Angus Salkeld asalk...@mirantis.com wrote:
Hi all
I just wanted to make sure we are all under the same understanding of the
outcomes and what the next steps for the versioned objects session are.
1. There is a lot of
I proposed a template change today [1] which adds an IPV6 Impact
section into the template specification. This was done after some
discussion on the Kilo Priorities spec [2] around IPV6. Given how
important IPV6 is, it's my opinion we should ensure specifications for
Kilo and beyond think about
Danny-
Availability zones and host aggregates are your friend. For more detail check
out:
http://docs.openstack.org/openstack-ops/content/scaling.html
--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786
From: Danny Choi (dannchoi)
Hi everyone,
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday November 25th, at 19:00 UTC in #openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone
3. vish brought up one draw back of versioned objects: the difficulty in
cherry picking commits for stable branches - Is this a show stopper?.
After some discussion with some of the interested parties, we're
planning to add a third .z element to the version numbers and use that
to handle
Hi all,
As far as oslo.messaging is concerned, should it be possible for the
main application to safely os.fork() when there is already an active
connection to a messaging broker?
I ask because I'm hitting what appears to be fork-related issues with
the new AMQP 1.0 driver. I think the same
One of the selling points of tripleo is to reuse as much as possible from the
cloud, to make it easier to deploy. While monasca may be more complicated, if
it ends up being a component everyone learns, then its not as bad as needing to
learn two different monitoring technologies. You could say
Dan Smith wrote:
3. vish brought up one draw back of versioned objects: the difficulty in
cherry picking commits for stable branches - Is this a show stopper?.
After some discussion with some of the interested parties, we're
planning to add a third .z element to the version numbers and use
This job was always experimental IIRC, and the original author hasn't
been around in a while. I agree we should remove it.
Michael
On Tue, Nov 25, 2014 at 4:52 AM, Sean Dague s...@dague.net wrote:
The pylint test job has been broken for weeks, no one seemed to care.
While waiting for other
On Nov 24, 2014, at 12:57 PM, Mike Bayer mba...@redhat.com wrote:
On Nov 24, 2014, at 12:40 PM, Doug Hellmann d...@doughellmann.com wrote:
This is a good point. I’m not sure we can say “we’ll only use
explicit/implicit async in certain cases because most of our apps actually
mix the
Doug Hellmann wrote:
On Nov 24, 2014, at 12:57 PM, Mike Bayermba...@redhat.com wrote:
On Nov 24, 2014, at 12:40 PM, Doug Hellmannd...@doughellmann.com wrote:
This is a good point. I’m not sure we can say “we’ll only use explicit/implicit
async in certain cases because most of our apps
Hi Samuel,
We've actually been avoiding having a deeper discussion about status in
Neutron LBaaS since this can get pretty hairy as the back-end
implementations get more complicated. I suspect managing that is probably
one of the bigger reasons we have disagreements around object sharing.
Perhaps
replication logs
On Thu, Nov 20, 2014 at 9:32 PM, Matsuda, Kenichiro
matsuda_keni...@jp.fujitsu.com wrote:
Hi,
Thank you for the info.
I was able to get replication info easily by swift-recon API.
But, I wasn't able to judge whether no failure from recon info of
object-replicator.
On 11/24/2014 03:11 PM, Joshua Harlow wrote:
Dan Smith wrote:
3. vish brought up one draw back of versioned objects: the difficulty in
cherry picking commits for stable branches - Is this a show stopper?.
After some discussion with some of the interested parties, we're
planning to add a third
Thank you all for the reply's to this thread. I have now set all of the
listed spec's to an abandoned state, Please note that any review can be
recovered quickly but clicking the Restore Change button. If one of the
listed spec's is restored please be sure to re-target to the Kilo cycle.
Thank
Hi all,
Ironic has decided to email a weekly status report for all subteams.
This is the inaugural issue of that. :)
This is and will be a copy and paste from the Ironic whiteboard.[0]
Testing (adam_g)
(deva)
- make Ironic voting -- needs to be rebased again, but has been approved
Bugs
On Nov 24, 2014, at 13:06, Jay Pipes jaypi...@gmail.com wrote:
That said, I don't think it's wise to make oslo-versionedobjects be a totally
new thing. I think we should use nova.objects as the base of a new
oslo-versionedobjects library, and we should evolve oslo-versionedobjects
slowly
On Tue, Nov 25, 2014 at 7:06 AM, Jay Pipes jaypi...@gmail.com wrote:
On 11/24/2014 03:11 PM, Joshua Harlow wrote:
Dan Smith wrote:
3. vish brought up one draw back of versioned objects: the difficulty in
cherry picking commits for stable branches - Is this a show stopper?.
After some
Heya,
Review https://review.openstack.org/#/c/135644/4 proposes the addition
of a new database for our improved implementation of cells in Nova.
However, there's an outstanding question about how to handle soft
delete of rows -- we believe that we need to soft delete for forensic
purposes.
This
I’ve also added APIImpact flag info to the Git Commit Messages page [1].
Everett
[1]
https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references
On Nov 19, 2014, at 5:23 PM, Everett Toews
everett.to...@rackspace.commailto:everett.to...@rackspace.com wrote:
On Nov 13,
My impression is that the statuses of each entity will be shown on a
detailed info request of a loadbalancer. The root level objects would
not have any statuses. For example a user makes a GET request
to /loadbalancers/{lb_id} and the status of every child of that load
balancer is show in a
Hi folks!
Since:
* The agenda contains no earth-shattering updates (ie. just going over
review progress)
* Nearly all the people working on Octavia are US-based
* The meeting is in the afternoon for most folks
* Wednesday is the day before a long holiday weekend and many employers
give their
Don,
Could the spec linked to your BP be moved to the specs repository?
I'm hesitant to start reading it as a google doc when I know I'm going
to want to make comments and ask questions.
Carl
On Thu, Nov 13, 2014 at 9:19 AM, Don Kehn dek...@gmail.com wrote:
If this shows up twice sorry for the
I am pleased to nominate Thai Tran and Cindy Lu to horizon-core.
Both Thai and Cindy have been contributing significant numbers of high
quality reviews during Juno and Kilo cycles. They are consistently among
the top non-core reviewers. They are also responsible for a significant
number of
First off, sorry for the slow reply. I was on vacation last week.
The project priority list was produced as part of the design summit,
and reflects nova's need to pay down technical debt in order to keep
meeting our users needs. So, whilst driver changes are important, they
doesn't belong on that
Hi Michael,
On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:
First off, sorry for the slow reply. I was on vacation last week.
The project priority list was produced as part of the design summit,
and reflects nova's need to pay down technical debt in order to keep
On Tue, Nov 25, 2014 at 11:14 AM, Mike Bayer mba...@redhat.com wrote:
On Nov 24, 2014, at 5:20 PM, Michael Still mi...@stillhq.com wrote:
Heya,
Review https://review.openstack.org/#/c/135644/4 proposes the addition
of a new database for our improved implementation of cells in Nova.
Hi all,
We have updated our proposal to reflect more details on our proposal. The
opnfv wiki link should be public for now:
https://wiki.opnfv.org/collaborative_development_projects/rescuer
We currently limit the scope of the project to provide VM DR state, so that
we could make a K release
On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
apilo...@cloudbasesolutions.com wrote:
Hi Michael,
On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:
First off, sorry for the slow reply. I was on vacation last week.
The project priority list was produced as part of the
On 25 Nov 2014, at 02:35, Michael Still mi...@stillhq.com wrote:
On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
apilo...@cloudbasesolutions.com wrote:
Hi Michael,
On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:
First off, sorry for the slow reply. I was on
On 19 November 2014 at 11:31, Mark McClain m...@mcclain.xyz wrote:
All-
Over the last several months, the members of the Networking Program have
been discussing ways to improve the management of our program. When the
Quantum project was initially launched, we envisioned a combined service
1 - 100 of 135 matches
Mail list logo
