Are there any parity features you are aware of that aren't receiving
adequate developer/reviewer time? I'm not aware of any parity features that
are in a place where throwing more engineers at them is going to speed
anything up. Maybe Mark McClain (Nova parity leader) can provide some
better
On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:
On 08/05/2014 01:23 PM, Gary Kotton wrote:
Ok, thanks for the clarification. This means that it will not be done
automagically as it is today the tenant will need to create a Neutron
port and then pass that through.
FWIW, that's
Correct, this work is orthogonal to the parity work, which I understand is
coming along very nicely. Do new features in Nova also require parity -
https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks
(for example enables the MTU to be configured instead of via a
In many cases the users I've spoken to who are looking for a live path out
of nova-network on to neutron are actually completely OK with some API
service downtime (metadata service is an API service by their definition).
A little 'glitch' in the network is also OK for many of them.
Contrast
On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote:
On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote:
On 08/05/2014 01:23 PM, Gary Kotton wrote:
Ok, thanks for the clarification. This means that it will not be done
automagically as it is today the tenant
Hi Zang,
On Tue, Aug 5, 2014 at 1:18 PM, Zang MingJie zealot0...@gmail.com wrote:
Hi Mathieu:
We have deployed the new l2pop described in the previous mail in our
environment, and works pretty well. It solved the timing problem, and
also reduces lots of l2pop rpc calls. I'm going to file a
Hi,
I'm Masakazu Shinohara of Cyberagent corporation in Japan.
I am a representative of our new cloud network project.
We have a lot of services such as on line games blogs or all kind of web
services.
Now we have been testing Openstack and Cisco ACI.
It is a really important thing that they
On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton gkot...@vmware.com wrote:
Correct, this work is orthogonal to the parity work, which I understand is
coming along very nicely.
Agree Gary and Kevin. I think the topic of Nova integration has
created confusion in people’s mind (at least the
From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:09 AM
To: OpenStack List
Ben Nemec openst...@nemebean.com writes:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
When you're developing some big change you'll end up with trying
dozens of different approaches and make thousands of mistakes. For
reviewers this is just unnecessary noise (commit title Scratch my
last
Thank you so much ! I had the same problem yesterday and was out of
ideas to solve this.
Matthieu Huin
m...@enovance.com
- Original Message -
From: Alexei Kornienko alexei.kornie...@gmail.com
To: openstack-dev@lists.openstack.org
Sent: Tuesday, August 5, 2014 10:08:45 PM
Subject:
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:
From: Aaron Rosen aaronoro...@gmail.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:09 AM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re:
As we are before next milestone, let's get back to this excellent (in my
opinion) proposal from Dmitry. Current situation is the following: there
are 121 blueprints targeted for 6.0. Most of them miss a header with
QA/reviewers/developers information, basically those are incomplete
blueprints
Hi,
In my company (Vodafone), we (DC network architecture) are following very
closely the work happening on Group Based Policy since we see a great value
on the new paradigm to drive network configurations with an advanced logic.
We're working on a new production project for an internal private
I'd like to stress this to everyone: I DO NOT propose squashing together
commits that should belong to separate change requests. I DO NOT propose to
upload all your changes at once. I DO propose letting developers to keep
local history of all iterations they have with a change request. The
history
Hi,
I really like what Mike proposed. It will help us to keep milestone clean
and accurate.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Wed, Aug 6, 2014 at 11:26 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
As we are before next milestone, let's get back to this
From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 11:11 AM
To: OpenStack List
Le 06/08/2014 10:35, Yuriy Taraday a écrit :
I'd like to stress this to everyone: I DO NOT propose squashing
together commits that should belong to separate change requests. I DO
NOT propose to upload all your changes at once. I DO propose letting
developers to keep local history of all
On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote:
Thanks. To facilitate quicker backport, you may also propose the patch
for review yourself. It may take time before stable maintainers or
other interested parties get to the bug and do cherry-pick.
Thank you for your advice.
I
Already agreed with the idea at the midcycle, but just making it public: +1
On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko
rprikhodche...@mirantis.com wrote:
Hi!
I think this is a nice idea indeed. Do you plan to use this process starting
from Juno or as soon as possible?
It will start
On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza sba...@redhat.com wrote:
Le 06/08/2014 10:35, Yuriy Taraday a écrit :
I'd like to stress this to everyone: I DO NOT propose squashing together
commits that should belong to separate change requests. I DO NOT propose to
upload all your changes
Hi,
Recently , the Tox runs started to fail in my workspace.
It fails consistently during installing dependencies with the following.
Downloading/unpacking PrettyTable=0.7,0.8 (from
python-keystoneclient=0.10.0--r
/home/narasimv/dev/bug1350485/neutron/requirements.txt (line 22))
Cleaning
On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen aaronoro...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:
From: Aaron Rosen aaronoro...@gmail.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:09
Hi,
Can you reach pypi.python.org ?
Matthieu Huin
m...@enovance.com
- Original Message -
From: Vivekanandan Narasimhan vivekanandan.narasim...@hp.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Wednesday, August 6, 2014
Hi,
Actually the same question, what is wrong with Tox now?
-- Igor
On Wed, Aug 6, 2014 at 1:19 PM, Narasimhan, Vivekanandan
vivekanandan.narasim...@hp.com wrote:
Hi,
Recently , the Tox runs started to fail in my workspace.
It fails consistently during installing dependencies with
Thank you for your suggestion.
I will investigate it and see how to integrate the trust model in the heat
template (if possible).
Regards,
Marouen Mechtri
2014-08-06 5:23 GMT+02:00 Don Waterloo don.water...@gmail.com:
On 5 August 2014 18:10, marwen mechtri mechtri.mar...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:19 PM, Narasimhan, Vivekanandan
vivekanandan.narasim...@hp.com wrote:
Timeout:
(pip._vendor.requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x37e4790, 'Connection to pypi.python.org timed out. (connect
timeout=15)')
I think this error
On 08/06/2014 05:23 AM, Don Waterloo wrote:
On 5 August 2014 18:10, marwen mechtri mechtri.mar...@gmail.com wrote:
Hi all,
I want to present you our OpenStack Heat installation guide for Icehouse
release.
I agree. the current status can reflect the deployment status and we can add a
new attribute to reflect operational status.
I also agree that adminstate_up should definitely affect operational status.
But driver could choose to unprovision when admin state is set to false. In
which case status
Hi!
Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113
The question is whether the python-pillow package really needed for
proper compiling css from scss in Horizon or is it an optional
requirement which can be safely dropped? The problem with
python-pillow is that it
On Wed, Aug 6, 2014 at 3:11 AM, Aaron Rosen aaronoro...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote:
From: Aaron Rosen aaronoro...@gmail.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:09 AM
Hi stefano !
Yes, it's a pleasure to contribute and to join the documentation team.
Ok! I will send announcements to the other mailing list ;)
Regards,
Chaima
2014-08-06 1:15 GMT+02:00 Stefano Maffulli stef...@openstack.org:
On 08/03/2014 03:49 AM, chayma ghribi wrote:
I want to share
On Tue, Aug 5, 2014 at 6:17 PM, Robert Collins
robe...@robertcollins.net wrote:
Hi!
James has run into an issue implementing the multi-hypervisor spec
(http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/tripleo-juno-deploy-cloud-hypervisor-type.rst)
which we're hoping to
On 08/05/2014 05:24 PM, Sumit Naiksatam wrote:
On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/05/2014 04:26 PM, Stephen Wong wrote:
Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to
On 08/05/2014 06:13 PM, Kevin Benton wrote:
That makes sense. It's not quite a fair analogy though to compare to
reintroducing projects or tenants because Keystone endpoints aren't
'user-facing' so to speak. i.e. a regular user (application deployer,
instance operator, etc) should never have
Hi Andreas,
It's pleasure to work together on the OpenStack heat templates
documentation.
In our manual, we provide two templates with the associated descriptions
(and pictures).
The first one is useful when we deploy 2 interconnected VMs and the second
one can be used to update the template
On 08/06/2014 06:30 AM, Thierry Carrez wrote:
Hi everyone,
At the TC meeting yesterday we discussed Rally program request and
incubation request. We quickly dismissed the incubation request, as
Rally appears to be able to live happily on top of OpenStack and would
benefit from having a
Hi Igor /Matthieu,
I am getting random connection timeouts to pypi.python.org with my machine
behind the proxy when trying to run
Tox –e pep8
Dependency installation fails with the stack trace posted below.
However, similar issue does not occur when I use run_tests.sh to run the same
set
On 08/06/2014 09:11 AM, Russell Bryant wrote:
On 08/06/2014 06:30 AM, Thierry Carrez wrote:
Hi everyone,
At the TC meeting yesterday we discussed Rally program request and
incubation request. We quickly dismissed the incubation request, as
Rally appears to be able to live happily on top of
On Aug 6, 2014, at 1:11 AM, Aaron Rosen
aaronoro...@gmail.commailto:aaronoro...@gmail.com wrote:
I agree, I had actually proposed this here:
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port :),
though there are some issues we need to solve in neutron first --
Hi all,
Please note that we've changed keywords used to trigger recheck action in
murano-ci to 'retrigger murano-ci'.
We decided to do this in order to prevent OpenStack CI from triggering a
build each time a comment 'recheck murano-ci' is added. The main cause of
this is the regexp in
On 08/06/2014 09:44 AM, Sean Dague wrote:
Something that we need to figure out is given where we are in the
release cycle do we want to ask the QA team to go off and do Rally deep
dive now to try to pull it apart into the parts that make sense for
other programs to take in. There are always
On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
I'd like to stress this to everyone: I DO NOT propose squashing together
commits that should belong to separate change requests. I DO NOT propose to
upload all your changes at once. I DO propose letting developers to keep
local history of all
On 30-Jul-14 23:24, Zane Bitter wrote:
On 30/07/14 02:21, Anant Patil wrote:
On 28-Jul-14 22:37, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-07-28 07:25:24 -0700:
On 26/07/14 00:04, Anant Patil wrote:
When the stack is updated, a diff of updated template and current
Hi,
I see that the stack delete method is too long to comprehend easily
without going to-and-fro few times. I think we should refactor it and
move out the UpdateReplace related logic for backup stack to another
method. We can also move the user credentials deletion related logic to
another
Hi,
I see that the stack delete method is too long to comprehend easily
without going to-and-fro few times. I think we should refactor it and
move out the UpdateReplace related logic for backup stack to another
method. We can also move the user credentials deletion related logic to
another
On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton blak...@gmail.com wrote:
Are there any parity features you are aware of that aren't receiving
adequate developer/reviewer time? I'm not aware of any parity features that
are in a place where throwing more engineers at them is going to speed
On 06/08/14 10:37, Anant Patil wrote:
Hi,
I see that the stack delete method is too long to comprehend easily
without going to-and-fro few times. I think we should refactor it and
move out the UpdateReplace related logic for backup stack to another
method. We can also move the user credentials
This was my first run so if I missed something please ping me, esp if
you are in need of a stable branch (for those projects we do that for),
1. os-apply-config: no changes, 0.1.19
2. os-refresh-config: no changes, 0.1.7
3. os-collect-config: no changes, 0.1.25
4.
Folks,
It's come to our attention that some key individuals are not
fully up-to-date on gnocchi activities, so it being a good and
healthy thing to ensure we're as communicative as possible about
our roadmap, I've provided a high-level overview here of our
thinking. This is intended as a
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints
You see how you used the term endpoints there? :P
-jay
On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com
wrote:
On 08/05/2014 10:51 AM, ZZelle wrote:
Hi,
I like
On 06-Aug-14 20:20, Zane Bitter wrote:
On 06/08/14 10:37, Anant Patil wrote:
Hi,
I see that the stack delete method is too long to comprehend easily
without going to-and-fro few times. I think we should refactor it and
move out the UpdateReplace related logic for backup stack to another
Hi folks,
We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.
Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20140807T18
--
Sincerely yours,
Sergey Lukjanov
Hi everyone,
With the incredible growth of OpenStack, our development community is
facing complex challenges. How we handle those might determine the
ultimate success or failure of OpenStack.
With this cycle we hit new limits in our processes, tools and cultural
setup. This resulted in
Hi Joe,
Are you suggesting to stop/remove everything that is not related to Nova
Parity for the Juno release? Because then I fail to see why this and Mark's
proposal are targeted only to GBP.
In my humble opinion, these kind of concerns should be addressed at BP
approval time. Otherwise the
Similarly, I appreciated this idea when we discussed it at the mid-cycle and
doing so here.
+1
-Jay Faulkner
From: Lucas Alvares Gomes lucasago...@gmail.com
Sent: Wednesday, August 06, 2014 2:34 AM
To: OpenStack Development Mailing List (not for usage
On Wed, Aug 06, 2014 at 11:51:27AM -0400, Eoghan Glynn wrote:
You've touched on multiple trains-of-thought that could indeed
justify separate threads of their own.
I agree with your read on the diverging growth rates in the
strategic versus the tactical elements of the community.
I
Howdy!
Rumor has it that it's easy to distribute ML2 mech drivers as out-of-tree
add-on modules.
Is this true? Has it been done? Where would one find an example?
Cheers!
-Luke
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
It sounds to me like you are describing how a developer uses Keystone, not
a user. My reference to 'application deployer' was to someone trying to run
something like a mail server on an openstack cloud.
On Aug 6, 2014 7:07 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/05/2014 06:13 PM,
On 8/5/2014 12:39 PM, Solly Ross wrote:
Just to add my two cents, while I get that people need to run on older versions
of software,
at a certain point you have to bump the minimum version. Even libvirt 0.9.11
is from April 3rd 2012.
That's two and a third years old at this point. I think
In the weekly neutron meetings it hasn't been mentioned that any of these
items are at risk due to developer shortage. That's why I wanted Mark
McClain to reply here because he has been leading the parity effort.
On Aug 6, 2014 8:56 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 6,
As a cloud admin one needs to make sure the endpoints in keystone
publicurl, internalurl and adminurl all map to the right places in the
infrastructure. As a cloud user (for example when using the HP/RAX public
cloud that has multiple regions/endpoints) a user needs to be aware of
which region
On 06 Aug 2014, at 10:41, Sergii Golovatiuk sgolovat...@mirantis.com wrote:
Hi,
I really like what Mike proposed. It will help us to keep milestone clean and
accurate.
+1 for Mike’s proposal. New members will also benefit from that move: clean
picture will make easier to pick up features
We have diverged our attention towards nova-network- neutron parity on
this thread unnecessarily.
Can we discuss and collectively decide on what is the way forward for GBP
in Juno release?
Efforts have been made by the subteam starting from throwing PoC at last
summit to spec approval to code
On Tue, Aug 5, 2014 at 8:25 PM, Tom Fifield t...@openstack.org wrote:
On 06/08/14 03:54, Jay Pipes wrote:
On 08/05/2014 03:23 PM, Collins, Sean wrote:
On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote:
However, I think the cost to providing that path far outweighs
the benefit in
What I was referring to was also not Keystone's definition of an endpoint.
It's almost as if the term has many uses and was not invented for Keystone.
:-)
http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
Did a similar discussion occur when Heat wanted to use the word
On 04/08/14 19:18, Yuriy Taraday wrote:
Hello, git-review users!
I'd like to gather feedback on a feature I want to implement that might
turn out useful for you.
I like using Git for development. It allows me to keep track of current
development process, it remembers everything I ever did with
Hi All:
+1 Ivar. Yes the timing of the alternate proposal does make the notion of spec
reviews seem like a process tick mark with no seeming benefit. It is indeed
unfair to the folks who have put in a lot of effort with an approved spec to
have a workflow change pulled on them so late in the
This is the consequence of a proposal that is not following the standardized
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198
Well, I did bring this point during the Hong Kong Summit but as you can see my
comments were totally ignored:
Which kind of uncertainty are you referring to?
Given that the blueprint was approved long ago, and the code has been ready
and under review following those specs... I think GBP is probably the patch
with the least effort to be merged right now.
Ivar.
On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon
On 08/06/2014 01:40 AM, Tom Fifield wrote:
On 06/08/14 13:30, Robert Collins wrote:
On 6 August 2014 17:27, Tom Fifield t...@openstack.org wrote:
On 06/08/14 13:24, Robert Collins wrote:
What happened to your DB migrations then? :)
Sorry if I misunderstood, I thought we were talking
As Ronak said, this thread is starting to move in a lot of different
directions, ranging from correctness of the blueprint approval process to
nova/neutron integration, which are rather off topic.
In particular it seems things are being skewed towards a discussion around
nova parity, whereas
On 08/06/2014 01:22 PM, Kevin Benton wrote:
What I was referring to was also not Keystone's definition of an
endpoint. It's almost as if the term has many uses and was not invented
for Keystone. :-)
http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
Did a similar discussion
Hi Stackers!
So, Liyi Meng has an interesting patch up for Nova:
https://review.openstack.org/#/c/104876
that changes the way that the interval and number of retries is
calculated for a piece of code that waits around for a block device
mapping to become active.
Namely, the patch discards
Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
Edgar Magana
Jul 2 8:42 AM
Patch Set 13: Code-Review+2
All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.
That would suggest that you were happy with
Salvatore,
Can you expand on point 2? Not sure what means in this case to 'treat it
accordingly'.
Thanks,
Ivar.
On Wed, Aug 6, 2014 at 7:44 PM, Salvatore Orlando sorla...@nicira.com
wrote:
As Ronak said, this thread is starting to move in a lot of different
directions, ranging from
On 08/06/2014 04:30 AM, Stefano Santini wrote:
Hi,
In my company (Vodafone), we (DC network architecture) are following
very closely the work happening on Group Based Policy since we see a
great value on the new paradigm to drive network configurations with an
advanced logic.
We're working on
Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that All looks good to me!.
On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com wrote:
That is the beauty of the open source projects, there
Hi, Salvatore,
Thanks listing out the options.
Can you elaborate more on your 2nd option? Do you mean merge the patches and
mark the API as ‘experimental’?
Yapeng
From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, August 06, 2014 1:44 PM
To: OpenStack Development Mailing
Hi,
I've made my way through the group based policy code and blueprints and I'd
like ask several questions about it. My first question really is what is
the advantage that the new proposed group based policy model buys us?
Bobs says, The group-based policy BP approved for Juno addresses the
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
I'd like to stress this to everyone: I DO NOT propose squashing together
commits that should belong to separate change requests. I DO NOT propose
to
upload all your changes
Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:
[snip]
AFAICT, there is nothing that can be done with the GBP API that cannot
be done with the low-level regular Neutron API.
I'll take you up on that, Jay :)
How exactly do I specify behavior between two collections of ports
On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 03:35 AM, Yuriy Taraday wrote:
I'd like to stress this to everyone: I DO NOT propose squashing together
commits that should belong to separate change requests. I
Hi Aaron,
These are good questions, but can we move this to a different thread
labeled what is the point of group policy?
I don't want to derail this one again and we should stick to Salvatore's
options about the way to move forward with these code changes.
On Aug 6, 2014 12:42 PM, Aaron Rosen
On 08/06/2014 11:19 AM, Edgar Magana wrote:
That is the beauty of the open source projects, there is always a smartest
reviewer catching out the facts that you don¹t.
And yet, the specification clearly talks about 'endpoints' and nobody
caught it where it supposed to be caught so I fear that
On Wed, Aug 6, 2014 at 2:07 PM, Stefano Maffulli stef...@openstack.org wrote:
On 08/06/2014 11:19 AM, Edgar Magana wrote:
That is the beauty of the open source projects, there is always a smartest
reviewer catching out the facts that you don¹t.
And yet, the specification clearly talks about
Hi Ryan,
On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote:
Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:
[snip]
AFAICT, there is nothing that can be done with the GBP API that cannot
be done with the low-level regular Neutron API.
I'll take you up
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com wrote:
On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com
wrote:
On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
+1
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Wednesday, August 06, 2014 10:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward
This is the consequence of a proposal that is not
Hi Kevin,
I think we should keep these threads together as we need to understand the
benefit collectively before we move forward with what to do.
Aaron
On Wed, Aug 6, 2014 at 12:03 PM, Kevin Benton blak...@gmail.com wrote:
Hi Aaron,
These are good questions, but can we move this to a
As long as the discussion stays focused on how group policies are
beneficial for the user community and how the Neutron developer community
should move forward, I reckon it's fine to keep the discussion in this
thread.
Salvatore
Il 06/ago/2014 21:18 Aaron Rosen aaronoro...@gmail.com ha scritto:
Hi Aaron,
Please note that the user using the current reference implementation
doesn't need to create Networks, Ports, or anything else. As a matter of
fact, the mapping is done implicitly.
Also, I agree with Kevin when he says that this is a whole different
discussion.
Thanks,
Ivar.
On Wed,
On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
Hi Aaron,
Please note that the user using the current reference implementation
doesn't need to create Networks, Ports, or anything else. As a matter of
fact, the mapping is done implicitly.
The user still needs to
Hi, folks!
Two months ago there was an announcement in ML about gathering the
requirements for cross-project UI library for
Heat/Mistral/Murano/Solum [1]. The positive feedback in related
googledoc [2] and some IRC chats and emails that followed convinced me
that I'm not the only person
Yamamoto has reviewed the changes for this, and has raised the following issue
(among others).
* iirc mellanox uses mac address as port identifier. what happens on
address change?
Can someone who knows mellanox please comment, either here or in the review?
Thanks,
Chuck
On Aug 5, 2014,
I believe the referential security group rules solve this problem (unless
I'm not understanding):
I think the disconnect is that you are comparing the way to current mapping
driver implements things for the reference implementation with the existing
APIs. Under this light, it's not going to look
Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 02:12:05 PM:
From: Aaron Rosen aaronoro...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 08/06/2014 02:12 PM
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based
The translation to creating a network is what is being done implicitly.
Another plugin could choose to implement this entirely using something like
security groups on a single giant network.
On Wed, Aug 6, 2014 at 1:38 PM, Aaron Rosen aaronoro...@gmail.com wrote:
On Wed, Aug 6, 2014 at
On 08/06/2014 03:46 PM, Kevin Benton wrote:
I believe the referential security group rules solve this problem
(unless I'm not understanding):
I think the disconnect is that you are comparing the way to current
mapping driver implements things for the reference implementation with
the existing
1 - 100 of 197 matches
Mail list logo
