Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.
Edgar
On 8/6/14, 11:32 AM, "Sumit Naiksatam" wrote:
>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch,
+1 Eugene,
Still, there's a point in Stefano's thread:
There's a time for discussing merging strategies, models, and naming
conventions... And this time is called BP approval :)
Just saying.
Ivar.
On Wed, Aug 6, 2014 at 10:21 PM, Eugene Nikanorov
wrote:
>
>
>
> On Wed, Aug 6, 2014 at 11:07
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12: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 t
On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats wrote:
> Aaron Rosen wrote on 08/06/2014 02:12:05 PM:
>
> > From: Aaron Rosen
>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >
> > Date: 08/06/2014 02:12 PM
> > Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based P
On Wed, Aug 6, 2014 at 11:07 PM, Stefano Maffulli
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 'endpoints
On Wed, Aug 6, 2014 at 12: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 wi
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
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 wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro
Aaron Rosen wrote on 08/06/2014 02:12:05 PM:
> From: Aaron Rosen
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 08/06/2014 02:12 PM
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
> and the way forward
>
> Hi Ryan,
>
> On Wed, Aug 6, 2014 at
>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
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,
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 interested
On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro 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 create an endpoi
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, 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" ha scritto:
> Hi Kevin,
>
> I th
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 wrote:
> Hi Aaron,
>
> These are good questions, but can we move this to a different thread
> l
+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 follow
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec wrote:
> On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec
> wrote:
> >
> >> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> >>> On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
> >> wrote:
> >>>
> On 08/05/2014 10
Hi Ryan,
On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats wrote:
> Jay Pipes 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 ex
On Wed, Aug 6, 2014 at 2:07 PM, Stefano Maffulli 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 'endpoints' and
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 s
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 01:42 PM, Yuriy Taraday wrote:
> On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec 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 propo
Jay Pipes 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 residing
in the sa
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec 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 at once. I DO
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
>
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 Li
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 wrote:
> That is the beauty of the open source projects, there is always a smartest
>
I'm not following here - you complain about rally being monolithic,
then suggest that parts of it should be baked into tempest - a tool
that is already huge and difficult to get into. I'd rather see tools
that do one thing well and some overlap than one tool to rule them
all.
On 6 August 2014 14:4
That is the beauty of the open source projects, there is always a smartest
reviewer catching out the facts that you don¹t.
Edgar
On 8/6/14, 10:55 AM, "Sumit Naiksatam" wrote:
>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>
>"
>Edgar Magana
>Jul 2 8:42 AM
>
>Patch Set 13: Code-Rev
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 a
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
wrote:
> As Ronak said, this thread is starting to move in a lot of different
> directions, ranging from correctness of the bluepri
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
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 t
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 oc
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 actua
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 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 about running VM
downti
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
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:
https://docs.google
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 cy
On Aug 6, 2014 10:21 AM, "Ronak Shah" wrote:
>
> 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
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
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 'template
On Tue, Aug 5, 2014 at 8:25 PM, Tom Fifield 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
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 re
On 06 Aug 2014, at 10:41, Sergii Golovatiuk 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 to work on.
Regards
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 maps
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" wrote:
>
>
>
> On Wed, Aug 6, 2014 at 4:12 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 a
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" wrote:
> On 08/05/2014 06:13 PM, Kevin Benton wrote:
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
http://list
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.
>
Similarly, I appreciated this idea when we discussed it at the mid-cycle and
doing so here.
+1
-Jay Faulkner
From: Lucas Alvares Gomes
Sent: Wednesday, August 06, 2014 2:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re:
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 whol
> 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 resu
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+Meeting&iso=20140807T18
--
Sincerely yours,
Sergey Lukjanov
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
On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
> On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec wrote:
>
>> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
>>> On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
>> wrote:
>>>
On 08/05/2014 10:51 AM, ZZelle wrote:
> Hi,
>
>
> I like the idea .
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
__
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 precurso
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. os-cloud-c
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
On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton 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
> anything up. Maybe Ma
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 metho
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 metho
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 c
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 ite
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
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 OpenStack'
On Aug 6, 2014, at 1:11 AM, Aaron Rosen
mailto: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 -- allowing the
mac_address o
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 o
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 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 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 (keep
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 hav
On 08/05/2014 05:24 PM, Sumit Naiksatam wrote:
> On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes 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 add
>>>
On Tue, Aug 5, 2014 at 6:17 PM, Robert Collins
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 use to reduce infrastru
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 :
> On 08/03/2014 03:49 AM, chayma ghribi wrote:
> > I want to share with you our OpenStac
On Wed, Aug 6, 2014 at 3:11 AM, Aaron Rosen wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton wrote:
>>
>>
>>
>> From: Aaron Rosen
>> Reply-To: OpenStack List
>> Date: Wednesday, August 6, 2014 at 10:09 AM
>>
>> To: OpenStack List
>> Subject: Re: [openstack-dev] [Neutron] Group Based
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 pull
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
On 08/06/2014 05:23 AM, Don Waterloo wrote:
> On 5 August 2014 18:10, marwen mechtri wrote:
>> Hi all,
>>
>> I want to present you our OpenStack Heat installation guide for Icehouse
>> release.
>>
>> https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installat
On Wed, Aug 6, 2014 at 12:19 PM, Narasimhan, Vivekanandan <
vivekanandan.narasim...@hp.com> wrote:
> Timeout:
> ( object at 0x37e4790>, 'Connection to pypi.python.org timed out. (connect
> timeout=15)')
>
I think this error message is pretty self explanatory
Chmouel
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 release cycle decoupled from the OpenStack
"integrated re
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 :
> On 5 August 2014 18:10, marwen mechtri wrote:
> > Hi all,
> >
> > I want to present you our Ope
Hi,
Can you reach pypi.python.org ?
Matthieu Huin
m...@enovance.com
- Original Message -
> From: "Vivekanandan Narasimhan"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Wednesday, August 6, 2014 12:19:57 PM
> Subject: [openstack-dev] Tox run failure
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
On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton wrote:
>
>>
>>
>> From: Aaron Rosen
>> Reply-To: OpenStack List
>> Date: Wednesday, August 6, 2014 at 10:09 AM
>>
>> To: OpenStack List
>> Subject: Re: [openstack-dev] [Neutron] Group Bas
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))
Clean
On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza 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 at once. 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
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 in Kilo
___
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 wo
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 iterat
From: Aaron Rosen mailto:aaronoro...@gmail.com>>
Reply-To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 11:11 AM
To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way fo
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
wrote:
> As we are before next milestone, let's get back to this excellent (in my
> opin
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,
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 c
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 initi
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton wrote:
>
>
> From: Aaron Rosen
> Reply-To: OpenStack List
> Date: Wednesday, August 6, 2014 at 10:09 AM
>
> To: OpenStack List
> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> forward
>
>
> On Tue, Aug 5, 2014 at 11:18 PM,
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"
> To: openstack-dev@lists.openstack.org
> Sent: Tuesday, August 5, 2014 10:08:45 PM
> Subject: Re: [openstack-dev] [N
101 - 200 of 207 matches
Mail list logo
