If the neutron side MD is just for snabbswitch, then I thinks there is no
change to be merged into the tree. Maybe we can learn from sriov nic,
although backend is vendor specific, but the MD is generic, can support
snabb, dpdkovs, ans other userspace vswitch, etc.
As the reference implementation
How you solved this issue of syntax error. We are getting the same error:
# rally -v task start rally/doc/samples/tasks/scenarios/vm/boot-runcommand-
delete.json
Command failed, please check log for more info
2014-09-01 07:31:52.606 9155 CRITICAL rally [-] ParserError: while parsing
a flow
Hey guys,
in Ceilometer we're using consistent hash rings to do workload
partitioning[1]. We've considered generalizing your hash ring
implementation and moving it up to oslo, but unfortunately your
implementation is not actually consistent, which is our requirement.
Since you divide your
Hello team:
Most folks are going to be out on Monday September 1st, on account of it
being Labor Day in the US. Consequently, I'd like to cancel the the
Trove blueprint meeting this week.
See you guys at the regular Trove meeting on Wednesday.
Thanks,
Nikhil
Hi all,
I found two functionalities for keystone that could be against each other.
Multi-domain feature (This functionality is new in Juno.)
---
Link:
http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers
Keystone supports the option to
On 30/08/14 03:45, Steve Gordon wrote:
- Original Message -
From: Matthew Booth mbo...@redhat.com
On 14/08/14 12:41, Steve Gordon wrote:
- Original Message -
From: Matthew Booth mbo...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com
wrote:
On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote:
On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
pkila...@cisco.com wrote:
On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote:
On Sat, Aug 30, 2014 at 05:08:16PM +0100, Mark McLoughlin wrote:
Hey
The libvirt version_cap debacle continues to come up in conversation and
one perception of the whole thing appears to be:
A controversial patch was ninjaed by three Red Hat nova-cores and
then the same individuals
On Aug 27, 2014, at 1:47 AM, Salvatore Orlando sorla...@nicira.com wrote:
TL; DR
A few folks are proposing to stop running tests for neutron advanced services
[ie: (lb|vpn|fw)aas] in the integrated gate, and run them only on the neutron
gate.
Reason: projects like nova are 100%
Hi,
As usually, this is a reminder about team meeting today at 16.00 UTC
#openstack-meeting.
Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Release 0.1 progress
Open discussion
(See it also at https://wiki.openstack.org/wiki/Meetings/MistralAgenda as
Hi All,
As a part of the implementation of Convergence BP, I have submitted change
(https://review.openstack.org/#/c/118143/ ) for moving the implementation of
check_create_complete method of 'server' resource to Observer. To start with,
for Juno, the convergence feature will be turned off by
Hello,
Not all features which had already been shipped in Neutron supported by
Horizon. For example, multi provider network.
This is not the special case only happened in Neutron. For example, Glance
delivered V2 api in IceHouse or even early and support Image muti-locations
feature, but
On Fri, Aug 29, 2014 at 5:03 PM, Stefano Maffulli stef...@openstack.org
wrote:
On Fri 29 Aug 2014 12:47:00 PM PDT, Elizabeth K. Joseph wrote:
Third-party-request
This list is the new place to request the creation or modification of
your third party account. Note that old requests sent to
Kyle, Adam,
Based on this thread Kyle is suggesting the follow moving forward plan:
1) We incubate Neutron LBaaS V2 in the “Neutron” incubator “and freeze
LBaas V1.0”
2) “Eventually” It graduates into a project under the networking program.
3) “At that point” We deprecate Neutron LBaaS v1.
Sure, Horizon (or Heat) support is not always required for new features
entering incubation, but when a goal in incubating a feature is to get
it packaged with OpenStack distributions and into the hands of as many
early adopters as possible to gather feedback, these integrations are
very
John Garbutt j...@johngarbutt.com wrote on 08/29/2014 07:59:38 PM:
From: John Garbutt j...@johngarbutt.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 08/29/2014 08:12 PM
Subject: Re: [openstack-dev] [nova] refactoring of
I'm happy to announce that Swift 2.1.0 has been released. This release includes
several useful features that I'd like to highlight.
First, Swift's data placement algorithm was slightly changed to improve adding
capacity. Specifically, now when you add a new region to an existing Swift
cluster,
I've been looking at the most recent patch for this
(https://review.openstack.org/#/c/117988/).
I'm wondering what behaviour do folks feel is best in the following scenario?
1) an image download starts (download1)
2) send SIGHUP to glance-api
3) start another download (download2)
4)
Thanks for joining our team meeting today!
Minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-09-01-16.00.html
Log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-09-01-16.00.log.html
Agenda/archive:
On Aug 29, 2014, at 6:28 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/28/2014 11:14 AM, Doug Hellmann wrote:
Before Juno we set a deprecation policy for graduating libraries that said
the incubated versions of the modules would stay in the incubator repository
for one full cycle after
On Aug 29, 2014, at 5:53 AM, Flavio Percoco fla...@redhat.com wrote:
On 08/28/2014 06:14 PM, Doug Hellmann wrote:
Before Juno we set a deprecation policy for graduating libraries that said
the incubated versions of the modules would stay in the incubator repository
for one full cycle after
On Aug 29, 2014, at 5:07 AM, Thierry Carrez thie...@openstack.org wrote:
Joe Gordon wrote:
On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:
I share Donald's points here, I believe what would help is to
clearly
Hello all,
I recently submitted this change:
https://review.openstack.org/#/c/118190/
This causes the Docker plugin to *remove* containers on delete,
rather than simply *stopping* them. When creating named containers,
the stop but do not remove behavior would cause conflicts when try
to
Hi,
This is the etherpad link to discuss the structure and content of the Audio
Visual content to be included in the training-guides.
https://etherpad.openstack.org/p/openstck-training-guides%28Audio_Visual_Content%29
Please feel free to add or edit the content here.
Regards,
Sayali.
I've got a review in progress for adding a telemetry scenario test:
https://review.openstack.org/#/c/115971/
It can't pass the *-icehouse tests because ceilometer-api is not present
on the icehouse side of a havana-icehouse upgrade.
In the process of trying to figure out what's going on I
Hi everyone,
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday September 2nd, 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
Timur,
I am excited to hear that you think that Barricade could be used in
Merlin! Your feedback is fantastic and I am impressed that you have been
able to understand Barricade so well from only the source and the spec.
I am replying to your feedback inline:
On 8/29/14, 2:59 PM, Timur Sufiev
On Fri, 2014-08-29 at 17:56 +0200, Thierry Carrez wrote:
Hayes, Graham wrote:
Yep, I think this works in theory, the tough part will be when all the
incubating projects realize they're sending people for a single day?
Maybe it'll work out differently than I think though. It means fitting
On Aug 28, 2014, at 7:57 AM, Thierry Carrez thie...@openstack.org wrote:
Thierry Carrez wrote:
Doug Hellmann wrote:
This makes sense to me, so let’s move ahead with your plan.
OK, this is now done:
Project group @ https://launchpad.net/oslo
Oslo incubator:
We should not confuse beta and rc builds, normally betas predate RCs and
serve a different purpose. In that sense, the nightlies we currently
publish are closest to what beta builds should be.
As discussed earlier in the thread, we already have full versioning and
provenance information in each
Per discussion again today in the Neutron meeting, next week we'll
start rotating the meeting. This will mean next week we'll meet on
Tuesday (9-9-2014) at 1400 UTC in #openstack-meeting-alt.
I've updated the Neutron meeting page [1] as well as the meeting wiki
page [2] with the new details on
Is it possible to put an iCal on the wiki so we can automatically see when
meetings are updated/cancelled/moved?
On Sep 1, 2014 6:23 PM, Kyle Mestery mest...@mestery.com wrote:
Per discussion again today in the Neutron meeting, next week we'll
start rotating the meeting. This will mean next
Hello,
1. As dashboard, Horizon even does not support all stable OpenStack API (
including Neutron API ), not mention to unstable API
2. For incubation feature, the introduced API is not stable and not necessary
for Horizon to support that.
3. The incubation feature could be experience by
Look on https://wiki.openstack.org/wiki/Meetings for a link to an iCal feed
of all OpenStack meetings.
https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
On Mon, Sep 1, 2014 at 8:26 PM, Kevin Benton blak...@gmail.com wrote:
Is it
Is it possible to have a /contrib folder or something similar where
experimental modules can be placed? Requiring a separate Horizon
distribution for every project in the incubator is really going to make it
difficult to get users to try them out.
On Mon, Sep 1, 2014 at 6:39 PM, joehuang
Unfortunately the master ICAL has so many meetings that it's not useful to
have displaying as part of a normal calendar.
I was hoping for a Neutron-specific one similar to Tripleo's.
On Mon, Sep 1, 2014 at 6:52 PM, Anne Gentle a...@openstack.org wrote:
Look on
Anthony,
Thanks for your reply.
If HA method like VRRP are used for IPv6 router, according to the VRRP
RFC with IPv6 included, the servers should be auto-configured with the
active router's LLA as the default route before the failover happens and
still remain that route after the failover.
I have had multiple occasions where the OpenDaylight CI will vote a -1 on a
patch for something completely unrelated (e.g. [1]). This would be fine
except for two issues. First, there doesn't appear to be any way to trigger
a recheck. Second, there is no maintainer listed on the Neutron third
I have had multiple occasions where the OpenDaylight CI will vote a -1 on a
patch for something completely unrelated (e.g. [1]). This would be fine
except for two issues. First, there doesn't appear to be any way to trigger
a recheck. Second, there is no maintainer listed on the Neutron third
It would satisfy everyone if horizon support all APIs, either in tree or in the
lab, but at the perquisite that we have enough resource for horizon.
Else for the limitation of resource, we have to sort by the priority, then
should we focus on APIs being baked in the incubator first?
Thank you YAMAMOTO. I didn't think to look at stackalytics.
Kyle, can you list yourself on the wiki? I don't want to do it in case
there is someone else doing that job full time.
Also, is there a re-trigger phrase that you can document on the Wiki or in
the message body the CI posts to the
Hi Gurus,
I saw the wiki page for Cinder Brick proposal for Havana, but I didn't see any
follow up on that idea. Is there any real progress on that idea?
As this proposal is to address the local storage issue, I'd like to know the
status, and to see if there is any task required for hypervisor
Definitely don't prioritize it. I was just saying that people developing
these would probably be happy to do all of the development and testing.
Is the resource limitation in Horizon on the reviewer side or the code
contribution side? I'm sure there are people familiar with Neutron that
would be
1) Forklift status
2) Next steps (now that Isolate Scheduler DB blueprint was rejected)
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
Hi Susanne and everyone,
My opinions are that keeping it in stackforge until it gets mature is
the best solution. I'm pretty sure we can all agree on that. Whenever
it is mature then, and only then, we should try to get it into openstack
one way or another. If Neutron LBaaS v2 is still
45 matches
Mail list logo
