Hi All,
I'm quite late to the discussion, because I'm on vacation and I missed
the beginning of this thread, but let me share a few thoughts.
On Fri, Sep 28, 2018 at 6:13 PM Jay Pipes wrote:
> * Does the provider belong to physical network "corpnet" and also
> support creation of virtual NICs of
Hi,
At the demo it turned out that people were interested in a written
version of the demo, so here you can find a blog post about the
current state of the guaranteed minimum bandwidth feature:
https://rubasov.github.io/2018/09/21/openstack-qos-min-bw-demo.html
Cheers,
Bence
On Thu, Sep 13, 2018
also cc-ed this mail so he/she can chime
in.
Cheers,
Bence Romsics
On Tue, Aug 7, 2018 at 1:32 PM Sean Mooney wrote:
>
> TL;DR
> it wont work with the ovs agent but "should" work with linux bridge.
> see full message below for details.
> regards
> sean.
>
> t
Sorry for the double post, I forgot the subject.
On Thu, Oct 12, 2017 at 2:29 PM, Bence Romsics wrote:
> Hi Horizon Folks,
>
> After the PTG I'm back from vacation and I'd like to ask for reviews
> for bp/neutron-trunk-ui:
>
> https://review.openstack.org/#/q/status
extension show trunk
d) Fetch the full patch series. Final patch: https://review.openstack.org/489186
The new panel should automatically appear as Project/Network/Trunks.
Background info on Neutron trunks:
* https://docs.openstack.org/neutron/pike/admin/config-trunking.html
* https://wiki.opens
Hi Robert,
I'm late to this thread, but let me add a bit. There was an attempt
for trunk support in nova metadata on the Pike PTG:
https://review.openstack.org/399076
But that was abandoned right after the PTG, because the agreement
seemed to be in favor of putting the trunk details into the upc
Hi,
On Thu, Mar 30, 2017 at 10:14 PM, KHAN, RAO ADNAN wrote:
> In Juno, there is an issue with instance rebuild (nova evacuate) when trunk
> port is associated with that instance.
I have a feeling you're not using the publicly available trunk port
version as available in Neutron since the Newton
The spec proposed can be found here:
https://review.openstack.org/424571
Cheers,
Bence Romsics
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
> If this is inside the Neutron tree, then support should live in the Horizon
> repo
This sounds like a conclusion. So I have abandoned the requests on
gerrit for the new repo.
Instead I just uploaded a Horizon blueprint draft for Pike:
https://blueprints.launchpad.net/horizon/+spec/neutron-tru
stack.org/428730
And the corresponding governance change:
https://review.openstack.org/428796
Please review them and if you agree approve. Or guide me to a better change.
Thanks in advance,
Bence Romsics
[1]
https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/conf
them.
Cheers,
Bence Romsics
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jay, let me correct myself. After a round of discussion with Armando
I'm no longer sure exactly what nova changes would be needed. The
discussion went into a direction where we started to question which
part of the change should fall into neutron and which part into nova.
I think joint nova-neutron
Hi,
Armando: Replied in the RFE comments. Let's continue there.
Jay: Yes, plus the corresponding changes in the API validator.
Practically this: https://review.openstack.org/383801
Cheers,
Bence
On Fri, Oct 7, 2016 at 5:30 PM, Jay Pipes wrote:
> On 10/07/2016 09:43 AM, Bence Romsi
Hi,
To follow up on the complications of bringing up trunk subports [1] I
have written up a small proposal for a tiny new feature affecting
neutron and nova. That is how to expose trunk details over metadata
API. To avoid big process overhead I have opened a newton rfe ticket
[2], plus a nova spec
Hi Kuba,
On Fri, Sep 30, 2016 at 3:38 PM, Jakub Libosvar wrote:
> The issue was with subports having different MAC addresses
> than MAC address of the parent port. Packets leaving virtual instance via
> VLAN interfaces (e.g. eth0.1) have always source MAC address of VLAN parent
> interface (e.g.
currently implemented approach I guess we can drop
the get_subports action, right?
Cheers,
Bence Romsics
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
Today there's no IRC meeting dedicated to the trunk port work. Most of
the discussion is going on in gerrit:
https://review.openstack.org/#/q/topic:bp/vlan-aware-vms+-status:abandoned
Or here in the mailing list. If you feel the need for it let us know
and we can easily revive it.
--
Bence
On M
change had to be reverted recently. Would be good to hear your
opinions on how to solve the remaining problems.
Bence Romsics
On Wed, Jun 15, 2016 at 8:01 PM, Peters, Rawlin wrote:
> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote:
>> >which generates an ar
your stuff.
Thanks.
Cheers,
Bence
On Tue, Aug 18, 2015 at 4:02 PM, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 08/18/2015 03:11 PM, Bence Romsics wrote:
>> Hi Ihar,
>>
>> Thank you. Just rebased my patch and following the exam
'extension_alias' property seems to be better not used, or
I still have the same error). Is that intentional?
Cheers,
Bence
On Mon, Aug 17, 2015 at 4:46 PM, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 08/17/2015 04:35 PM, Bence Ro
Hi All,
How do I implement one extension by two plugins?
If I extend the API by:
* a first class resource, and
* attributes to an already existing resource (the port resource in my case).
These two parts don't make sense without each other, so I'd like to
keep this as one extension, not two.
Th
Hi,
> When firewall_driver is set to NoopFirwallDriver in Neutron agent,
> uses can create security group and its rules, but no packet filtering
> is enforced.
> If neutron security group is enabled, users should expect packet
> filtering is enabled
> I think this behavior is confusing from Neutro
eve a noop driver
should look like it is present (in the list of available extensions), but
does nothing. The patch in review #23160 believes an other way and makes
the noop driver look like as if it wasn't even present. Which may lead to
your current bug.
Best regards,
Bence Romsics
On S
23 matches
Mail list logo
