On 8 August 2014 10:56, Kevin Benton wrote:
> There is an enforcement component to the group policy that allows you to
> use the current APIs and it's the reason that group policy is integrated
> into the neutron project. If someone uses the current APIs, the group
> policy plugin will make sure
>
> Adding the GBP extension to Neutron does not change the nature of the
> software architecture of Neutron making it more or less monolithic.
I agree with this statement...partially: the way GBP was developed is in
accordance to the same principles and architectural choices made for the
service
instead of
going after the better approach, we stick with the less optimal one?
>
> On Fri, Aug 8, 2014 at 1:45 PM, Armando M. wrote:
>
>> On 8 August 2014 10:56, Kevin Benton wrote:
>>
>>> There is an enforcement component to the group policy that allows you to
&
> One advantage of the service plugin is that one can leverage the neutron
> common framework such as Keystone authentication where common scoping is
> done. It would be important in the policy type of framework to have such
> scoping
>
The framework you're referring to is common and already reus
>
>
> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. wrote:
>
>>
>>
>>> One advantage of the service plugin is that one can leverage the
>>> neutron common framework such as Keystone authentication where common
>>> scoping is done. It would be im
On 9 August 2014 10:16, Jay Pipes wrote:
> Paul, does this friend of a friend have a reproduceable test script for
> this?
>
> Thanks!
> -jay
>
>
We would also need to know the OpenStack release where this issue manifest
itself. A number of bugs have been raised in the past around this type of
is
I am gonna add more color to this story by posting my replies on review [1]:
Hi Angus,
You touched on a number of points. Let me try to give you an answer to all
of them.
>> (I'll create a bug report too. I still haven't worked out which class of
changes need an accompanying bug report and which
>
>
> > At the moment pylint on neutron is *very* noisy, and I've been looking
> through
> > the reported issues by hand to get a feel for what's involved. Enabling
> > pylint is a separate discussion that I'd like to have - in some other
> thread.
> >
>
> I think enabling pylint check was discuss
Hi folks,
According to [1], we have ways to introduce external references to commit
messages.
These are useful to mark certain patches and their relevance in the context
of documentation, upgrades, etc.
I was wondering if it would be useful considering the addition of another
tag:
GateFailureFi
>
> A concern with this approach is it's pretty arbitrary, and not always
> clear which bugs are being addressed and how severe they are.
>
Well, establishing whether LP reports are actual bugs and assigning the
severity isn't what triaging is for?
>
> An idea that came up in the Infra/QA meetup
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take more than two cycles, and would
require a very focused team of people
On 10 September 2014 22:23, Russell Bryant wrote:
> On 09/10/2014 10:35 PM, Armando M. wrote:
>> Hi,
>>
>> I devoured this thread, so much it was interesting and full of
>> insights. It's not news that we've been pondering about this in the
>> Neutron pr
VLAN is on the radar, vxlan/gre was done to start with.
I believe Vivek mentioned the rationale in some other thread. The gist
of it below:
In the current architecture, we use a unique DVR MAC per compute node
to forward DVR Routed traffic directly to destination compute node.
The DVR routed traf
I have been doing so in the number of patches I pushed to reduce error
traces due to the communication between server and dhcp agent.
I wanted to take care of the l3 agent too, but one thing I noticed is
that I couldn't find a log for it (I mean on the artifacts that are
published at job's complet
To be fair, neutron cores turned down reviews [1][2][3] for fear that
the patch would break Hyper-V support for Neutron.
Whether it's been hinted (erroneously) that this was a packaging issue
is irrelevant for the sake of this discussion, and I suggested (when I
turned down review [3]) if we could
+1
On Feb 13, 2014 5:52 PM, "Nachi Ueno" wrote:
> +1
>
> 2014年2月12日水曜日、Mayur Patilさんは書きました:
>
>> +1
>>
>> *--*
>> *Cheers,*
>> *Mayur*
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailm
Thomas,
I feel your frustration, however before complaining please do follow
the actual chain of events.
Patch [1]: I asked a question which I never received an answer to.
Patch [2]: I did put a -1, but I have nothing against this patch per
se. This was only been recently abandoned and my -1 lied
On 20 February 2014 14:13, Vincent Untz wrote:
> Le jeudi 20 février 2014, à 12:02 -0800, Armando M. a écrit :
>> Thomas,
>>
>> I feel your frustration, however before complaining please do follow
>> the actual chain of events.
>>
>> Patch [1]: I asked a qu
Nice one!
On 21 February 2014 11:22, Aaron Rosen wrote:
> This should fix the false positive for brocade:
> https://review.openstack.org/#/c/75486/
>
> Aaron
>
>
> On Fri, Feb 21, 2014 at 10:34 AM, Aaron Rosen wrote:
>>
>> Hi,
>>
>> Yesterday, I pushed a patch to review and was surprised that se
Hi Carl,
Thanks for kicking this off. I am also willing to help as a core reviewer
of blueprints and code
submissions only.
As for the ML2 agent, we all know that for historic reasons Neutron has
grown to be not only a networking orchestration project but also a
reference implementation that is r
Mark, Kyle,
What is the strategy for tracking the progress and all the details about
this initiative? Blueprint spec, wiki page, or something else?
One thing I personally found useful about the spec approach adopted in [1],
was that we could quickly and effectively incorporate community feedback;
t;
> On 17 November 2014 01:13, Mathieu Rohon wrote:
>
>> Hi
>>
>> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote:
>> > Last Friday I recall we had two discussions around this topic. One in
>> the
>> > morning, which I think led to Maruti to push
>
So far it seems like proposal [1] that has the most momentum. I'd like to
consider [3] as one potential software implementation of the proposed API.
As I mentioned earlier, I'd rather start with a well defined problem, free
of any potential confusion or open to subjective interpretation
e for being outside of neutron's main repo (which, if you're
> following the discussions does not mean "outside of neutron"). The
> arguments I've seen so far do not yet convince me this thing has to be
> tightly integrated into the core neutron.
>
My work
Hi Henry,
Thanks for your input.
> No attention to argue on agent vs. agentless, built-in reference vs.
> external controller, Openstack is an open community. But, I just want
> to say that modularized agent re-factoring does make a lot of sense,
> while forcing customer to piggyback an extra SD
Hi Don,
You should look at this one:
https://wiki.openstack.org/wiki/NeutronSubteamCharters
Also, it would be good to start feeding the content of that gdoc into a
neutron-specs blueprint, using template [1] and process [2], bearing in
mind these dates [3]
1.
http://git.openstack.org/cgit/opens
Congrats to Henry and Kevin, +1!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi folks,
For a few weeks now the Neutron team has worked tirelessly on [1].
This initiative stems from the fact that as the project matures, evolution
of processes and contribution guidelines need to evolve with it. This is to
ensure that the project can keep on thriving in order to meet the nee
For anyone who had an interest in following this thread, they might want to
have a look at [1], and [2] (which is the tl;dr version [1]).
HTH
Armando
[1] https://review.openstack.org/#/c/134680
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052346.html
__
e text you quoted in the review makes that clear. We will look at
>> further decomposing ML2 post Kilo, but we have to be realistic with what we
>> can accomplish during Kilo.
>> >
>> > Find me on IRC Monday morning and we can discuss further if you still
>
iver/blob/icehouse/apic_ml2/neutron/db/migration/alembic_migrations/env.py
> [4]
> https://github.com/noironetworks/apic-ml2-driver/blob/icehouse/setup.cfg
> [5] https://github.com/openstack-dev/cookiecutter
> [6] https://github.com/stackforge/group-based-policy
>
> On Tue, Dec 9,
On 12 December 2014 at 22:18, Ryu Ishimoto wrote:
>
>
> Hi All,
>
> It's great to see the vendor plugin decomposition spec[1] finally getting
> merged! Now that the spec is completed, I have a question on how this may
> impact neutronclient, and in particular, its handling of vendor extensions.
>
is, ask oslo people,
>> >they did it plenty of times when graduating libraries from
>> oslo-incubator.
>> >/Ihar
>> >
>> >On 10/12/14 19:18, Cedric OLLIVIER wrote:
>> >> <https://review.openstack.org/#/c/140191/>
>> >>
>> >
This was more of a brute force fix!
I didn't have time to go with finesse, and instead I went in with the
hammer :)
That said, we want to make sure that the upgrade path to Kilo is as
painless as possible, so we'll need to review the Release Notes [1] to
reflect the fact that we'll be providing a
On 15 December 2014 at 09:53, Neil Jerram
wrote:
>
> Hi all,
>
> Following the approval for Neutron vendor code decomposition
> (https://review.openstack.org/#/c/134680/), I just wanted to comment
> that it appears to work fine to have an ML2 mechanism driver _entirely_
> out of tree, so long as t
>
>
>
> Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
> Who will be responsible for these drivers?
>
> Excellent question. In my opinion, 'technology' specific but not vendor
> specific MD (like SRIOV) should not be maintained by specific vendor. It
> should be accessible fo
>
> If we were standing at a place with a detailed manual upgrade document
> that explained how to do minimal VM downtime, that a few ops had gone
> through and proved out, that would be one thing. And we could figure out
> which parts made sense to put tooling around to make this easier for
> ever
+1
On 15 January 2015 at 14:46, Edgar Magana wrote:
> +1 For adding Doug as Core in Neutron!
>
> I have seen his work on the services part and he is a great member of
> the OpenStack community!
>
> Edgar
>
> From: Kyle Mestery
> Reply-To: "OpenStack Development Mailing List (not for usage
If the consensus is to unify all the config options into a single
configuration file, I'd suggest following what the Nova folks did with
[1], which I think is what Salvatore was also hinted. This will also
help mitigate needless source code conflicts that would inevitably
arise when merging competi
Hi Ilkka,
As Mathieu suggested there is a blueprint submission and revision
process put in place since the Juno release. Also, since Icehouse, to
incorporate a new plugin/mechanism driver into the Neutron source
tree, and to be designated as compatible, such a plugin/driver must be
accompanied by
+1 from me too: Carl's contributions, code and reviews, have helped raise
the quality of this project.
Cheers,
Armando
On 21 May 2014 15:05, Maru Newby wrote:
>
> On May 21, 2014, at 1:59 PM, Kyle Mestery wrote:
>
>> Neutron cores, please vote +1/-1 for the proposed addition of Carl
>> Baldwin
I would second Maru's concerns, and I would also like to add the following:
We need to acknowledge the fact that there are certain architectural
aspects of Neutron as a project that need to be addressed; at the
summit we talked about the core refactoring, a task oriented API, etc.
To me these item
nt around an effort that is still in inception phase is not a good
> solution. We are looking forward to participating in the core refactoring
> work, and based on the final spec that come up with, we would love to be
> able to eventually make the policy implementation simpler.
>
> Regards,
On 23 May 2014 12:31, Robert Kukura wrote:
>
> On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
>
> Hi Armando:
>
> Those are good points. I will let Bob Kukura chime in on the specifics of
> how we intend to do that integration. But if what you see in the
> prototype/PoC was our final design for integr
On 24 May 2014 05:20, Robert Kukura wrote:
>
> On 5/23/14, 10:54 PM, Armando M. wrote:
>>
>> On 23 May 2014 12:31, Robert Kukura wrote:
>>>
>>> On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
>>>
>>> Hi Armando:
>>>
>>> Those are
o some of the OpenStack
> > design principles.
>
>
> From the summit sessions (in particular the session by Mark on
refactoring the core), I too was under the impression that there will be a
way of invoking Neutron API within the plugin with the same semantics as
through the REST A
tation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/
><- GP design document
> [3]
> https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/
><- GP PoC document
>
>
> [image: Inactive hide details for "Armando M." ---05/26/20
Hi Keshava,
To the best of my knowledge Nova does not have an explicit way to determine
VM placements based on network attributes. That said, it does have a
general mechanism called host-aggregates [1] that can be leveraged to
address what you are looking for. How certain hosts are grouped togethe
Hi Paul,
Just out of curiosity, I am assuming you are using the client that
still relies on httplib2. Patch [1] replaced httplib2 with requests,
but I believe that a new client that incorporates this change has not
yet been published. I wonder if the failures you are referring to
manifest themselv
lly
> help here as it seems like an ssl thing itself. But... who knows?? I'm not
> sure how consistently we can
> recreate this, but if we can, I'll try using that patch to use requests and
> see if that helps.
>
>
>
> "Armando M." wrote on 05/29
I believe the Brocade's mech driver might have the same problem.
That said, if the content of the rpm that installs the BigSwitch plugin is
just the sub-tree for bigswitch (plus the config files, perhaps), you might
get away with this issue by just installing the bigswitch-plugin package. I
assume
just common code.
>
> Sort of like:
>
> common/brocade/templates
> common/bigswitch/*
>
> -Shiv
> From: "Armando M."
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
I wonder what the turnaround of trivial patches actually is, I bet you it's
very very small, and as Daniel said, the human burden is rather minimal (I
would be more concerned about slowing them down in the gate, but I digress).
I think that introducing a two-tier level for patch approval can only
just a provocative thought: If we used the ovsdb connection instead, do we
really need an L2 agent :P?
On 17 June 2014 18:38, Kyle Mestery wrote:
> Another area of improvement for the agent would be to move away from
> executing CLIs for port commands and instead use OVSDB. Terry Wilson
> and I
nature,
> we can
>
> enhance the Flow API (OVS-Lib) to provide more fine grained errors/return
> codes (or content)
>
> and ovs-agent (and even other components) can act on such return state
> more
>
> intelligently/appropriately.
>
>
>
> --
>
> Thanks,
>
Hi Simon,
You are absolutely right in your train of thoughts: unless the
third-party CI monitors and vets all the potential changes it cares
about there's always a chance something might break. This is why I
think it's important that each Neutron third party CI should not only
test Neutron changes
What about:
https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12
On 22 September 2014 10:23, Kevin L. Mitchell
wrote:
> My team just ran into an issue where neutron was not passing unit tests
> when run under Python 2.6. We tracked this down to a test support
> function
e appears to be:
>>
>> - python-2.6.6-ordereddict-backport.patch
>>
>> Full changelog @ http://paste.ubuntu.com/8405082/
>>
>> Overall I'd personally like to get rid of python 2.6, and move on, but then
>> I'd also like to get rid
I have all of these bugs on my radar, and I want to fast track them
for merging in the next few days.
Please tag the bug reports with 'juno-rc-potential'.
For each of them we can discuss the loss of functionality they cause.
If no workaround can be found, we should definitely cut an RC2.
Armando
As far as I can tell when you specify:
dhcp_agents_per_network = X > 1
The server binds the network to all the agents (up to X), which means that
you have multiple instances of dnsmasq serving dhcp requests at the same
time. If one agent dies, there is no fail-over needed per se, as the other
age
It sounds like the only reasonable option we are left with right now is to
document.
Even if we enabled/removed the backport, it would take time until users can
get their hands on a new cut of the stable branch.
We would need to be more diligent in the future and limit backports to just
bug fixes
other problem going on.
>
>
> I have the same problem wit L3 agents by the way, that's next on my list
>
> --
> Noel
>
>
> On Tue, Oct 21, 2014 at 12:52 PM, Armando M. wrote:
>
>> As far as I can tell when you specify:
>>
>> dhcp_agents_pe
Sorry for jumping into this thread late...there's lots of details to
process, and I needed time to digest!
Having said that, I'd like to recap before moving the discussion forward,
at the Summit and beyond.
As it's being pointed out, there are a few efforts targeting this area; I
think that is se
I must admit I haven't digged up too much, but this might also look
suspicious:
https://review.openstack.org/#/c/96782/
Perhaps it's a combination of both? :)
On 29 October 2014 08:17, Kyle Mestery wrote:
> On Wed, Oct 29, 2014 at 7:25 AM, Hly wrote:
> >
> >
> > Sent from my iPad
> >
> > On 2
Hi Eugene thanks for bringing this up for discussion. My comments inline.
Thanks,
Armando
On 5 November 2014 12:07, Eugene Nikanorov wrote:
> Hi folks,
>
> I'd like to raise a discussion kept in irc and in gerrit recently:
> https://review.openstack.org/#/c/131944/
>
> The intention of the patch
I would be open to making this toggle switch available, however I feel that
doing it via static configuration can introduce unnecessary burden to the
operator. Perhaps we could explore a way where the agent can figure which
state it's supposed to be in based on its reported status?
Armando
On 5 N
I have just realized that I should have cross-reference this mail on both
ML's. Same message for the dev mailing list.
Thanks,
Armando
On 6 November 2014 00:32, Armando M. wrote:
> Hi there,
>
> I know this may be somewhat short notice, but a few of us have wondered if
> we sh
Thanks for everyone who turned up!
It was nice seeing you there, it was last minute planning...but we manage
to squeeze in okay!
Cheers,
Armando
On 6 November 2014 17:16, Oleg Bondarev wrote:
> Please count me in.
>
> Thanks,
> Oleg
>
> ___
> OpenSta
Not sure if you've seen this one too:
https://wiki.openstack.org/wiki/Neutron/DVR
Hope this helps!
Armando
On 7 November 2014 01:50, Li Tianqing wrote:
> Oh, thanks, i finally find it.
> it's all here.
> https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
>
> Thanks a lot.
>
> -
Hi Miguel,
Thanks for picking this up. Pull me in and I'd be happy to help!
Cheers,
Armando
On 7 November 2014 10:05, Miguel Ángel Ajo wrote:
>
> Hi Yorik,
>
>I was talking with Mark Mcclain a minute ago here at the summit about
> this. And he told me that now at the start of the cycle loo
Hi there,
My answers inline. CC the dev list too.
On 13 November 2014 01:24, Gary Kotton wrote:
> Hi,
> At the moment the BP is blocked by the design on splitting out the vendor
> plugins.
>
We have implemented the NSXv plugin based on stable/icehouse and plan to
> start to push this upstream
I chimed in on another thread, but I am reinstating my point just in case.
On 13 November 2014 04:38, Gary Kotton wrote:
> Hi,
> A few months back we started to work on a umbrella spec for Vmware
> networking support (https://review.openstack.org/#/c/105369). There are a
> number of different p
Last Friday I recall we had two discussions around this topic. One in the
morning, which I think led to Maruti to push [1]. The way I understood [1]
was that it is an attempt at unifying [2] and [3], by choosing the API
approach of one and the architectural approach of the other.
[1] https://revie
Benjamin,
Feel free to reach out. If you are referring to my -2, that was just
provisional.
Before we can go ahead and see an improved scheduling capability for DHCP,
you guys need to resolve the conflict between the overlapping blueprints,
working together or giving up one in favor on the other.
Hello,
As follow-up action after the Design Summit Session on Core/Vendor split,
please find the proposal outlined here:
https://review.openstack.org/#/c/134680/
I know that Anita will tell me off since I asked for reviews on the ML, but
I felt that it was important to raise awareness, even more
On 17 November 2014 01:13, Mathieu Rohon wrote:
> Hi
>
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote:
> > Last Friday I recall we had two discussions around this topic. One in the
> > morning, which I think led to Maruti to push [1]. The way I understood
> [
Hi Gary,
Thanks for sending this out, comments inline.
On 29 June 2014 00:15, Gary Kotton wrote:
> Hi,
> At the moment there are a number of different BP’s that are proposed to
> enable different VMware network management solutions. The following specs
> are in review:
>
>1. VMware NSX-vS
Hi folks,
The DVR team is working really hard to complete this important task for
Juno and Neutron.
In order to help see this feature in action, a video has been made
available and link can be found in [2].
There is still some work to do, however I wanted to remind you that all of
the relevant i
nough people to make any
> >>progress.
> >
> >>Lets try again next week Monday at 14:00 UTC. The meeting will take place
> >
> >>on #openstack-vmware channel
> >
> >>Alut a continua
> >
> >>Gary
> >
> >>
> &g
I think the specs under the umbrella one can be approved/treated
individually.
The umbrella one is an informational blueprint, there is not going to be
code associated with it, however before approving it (and the individual
ones) we'd need all the parties interested in vsphere support for Neutron
That would be my thinking as well, but if we managed to make an impressive
progress from now until the Feature Freeze proposal deadline, I'd be
willing to reevaluate the situation.
A.
On 21 July 2014 12:13, Kyle Mestery wrote:
> On Mon, Jul 21, 2014 at 2:03 PM, Armando M. wrote:
>
It is not my intention debating, pointing fingers and finding culprits,
these issues can be addressed in some other context.
I am gonna say three things:
1) If a core-reviewer puts a -2, there must be a good reason for it. If
other reviewers blindly move on as some people seem to imply here, then
Hi,
When I think about Group-Based Policy I cannot help myself but think about
the degree of variety of sentiments (for lack of better words) that this
subject has raised over the past few months on the mailing list and/or
other venues.
I speak for myself when I say that when I look at the end-to
This thread is moving so fast I can't keep up!
The fact that troubles me is that I am unable to grasp how we move forward,
which was the point of this thread to start with. It seems we have 2
options:
- We make GBP to merge as is, in the Neutron tree, with some minor revision
(e.g. naming?);
- We
On 6 August 2014 15:47, Kevin Benton wrote:
> I think we should merge it and just prefix the API for now with
> '/your_application_will_break_after_juno_if_you_use_this/'
>
And you make your call based and what pros and cons exactly, If I am ask?
Let me start:
Option 1:
- pros
- immediat
>
> This is probably not intentional from your part ,but your choice of words
> make it seem that you are deriding the efforts of the team behind this
> effort. While i may disagree technically here and there with their current
> design, it seems to me that the effort in question is rather broad ba
On 6 August 2014 17:34, Prasad Vellanki
wrote:
> It seems like Option 1 would be preferable. User can use this right away.
>
>
People choosing Option 1 may think that the shortest route may be the best,
that said the drawback I identified is not to be dismissed either (and I am
sure there many m
Hi Salvatore,
I did notice the issue and I flagged this bug report:
https://bugs.launchpad.net/nova/+bug/1352141
I'll follow up.
Cheers,
Armando
On 7 August 2014 01:34, Salvatore Orlando wrote:
> I had to put the patch back on WIP because yesterday a bug causing a 100%
> failure rate slippe
Hi folks,
During revision of the Neutron teams [1], we made clear that the
neutron-specs repo is to be targeted by specs for all the Neutron projects
(core + *-aas).
For this reason I made sure that the neutron-specs-core team +2 right was
extended to all the core teams.
Be mindful, use your +2
Hi folks,
Henry has been instrumental in many areas of the projects and his crazy
working hours makes even Kevin and I bow in awe.
Jokes aside, I would like to announce HenryG as a new member of the Neutron
Drivers team.
Having a propension to attendance, and desire to review of RFEs puts you on
On 20 October 2015 at 19:46, Takashi Yamamoto wrote:
> i missed the "further notice"?
>
No, you didn't. RC3 released, Liberty released, the world moved on and I
didn't think of sending an email. Sorry.
>
> On Wed, Oct 14, 2015 at 4:07 AM, Armando M. wrote:
>
;
No, unless what you are asking are changes to the core. Do you have a
reference for me to look at?
>
> Any opinions on that?
>
> Gal.
>
> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. wrote:
>
>> Hi folks,
>>
>> During revision of the Neutron teams [1], we ma
On 21 October 2015 at 02:01, Ihar Hrachyshka wrote:
>
> > On 21 Oct 2015, at 05:14, Armando M. wrote:
> >
> > Hi folks,
> >
> > Henry has been instrumental in many areas of the projects and his crazy
> working hours makes even Kevin and I bow in awe.
On 21 October 2015 at 09:53, Kyle Mestery wrote:
> On Wed, Oct 21, 2015 at 11:37 AM, Armando M. wrote:
>
>>
>>
>> On 21 October 2015 at 04:12, Gal Sagie wrote:
>>
>>> Do we also want to consider Project Kuryr part of this?
>>>
>>
>
On 21 October 2015 at 09:52, Gal Sagie wrote:
>
>
> On Wed, Oct 21, 2015 at 7:37 PM, Armando M. wrote:
>
>>
>>
>> On 21 October 2015 at 04:12, Gal Sagie wrote:
>>
>>> Do we also want to consider Project Kuryr part of this?
>>>
>>
On 21 October 2015 at 10:29, Kyle Mestery wrote:
> On Wed, Oct 21, 2015 at 12:08 PM, Armando M. wrote:
>
>>
>>
>> On 21 October 2015 at 09:53, Kyle Mestery wrote:
>>
>>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M. wrote:
>>>
>>>
On 21 October 2015 at 15:40, Ildikó Váncsa
wrote:
> Hi Folks,
>
> During Liberty we started the implementation of the VLAN aware VMs
> blueprint (https://review.openstack.org/#/c/94612/). We had quite a good
> progress, although we could use some extra hands on Neutron side and some
> thoughts on
On 22 October 2015 at 01:21, yujie wrote:
> I used ixgbe and vlan, passthrough a VF to vm.
> After the VM created, it could not connect to VM on the same compute node
> without use sriov.
>
>
Not sure if this is the same conversation happening on Launchpad, but if
not, this might be relevant:
ht
Hi folks,
We currently have the submissions and only 6 slots. There's still some time
left before the end of this week.
Whoever put an entry in the etherpad [1], please consider adding your name,
otherwise we don't know who to reach out during the session [2]. If all
things stay the same, we'll p
A reminder that we won't have the meeting next week.
Safe journey back from Tokyo, for who has travelled to the Summit.
Cheers,
Armadno
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
1 - 100 of 673 matches
Mail list logo
