RE: openstack-discuss Digest, Vol 62, Issue 5 Netwok Configuration Isssue | Urgent - openstack-discuss

8 Dec 2023

      Hi openstack community,

I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses from the assigned networks which I have created provider and self-service flat network type. Hence, I may not be able to ping and ssh instance from the controller node and these instances won’t be able to connect to the internet. 

Can anyone guide me how to resolve this issue by pinpointing the initial network configurations settings.
-----Original Message-----
From: Asma Naz Shariq <asma.naz@techavenue.biz> 
Sent: Wednesday, December 6, 2023 10:42 AM
To: 'openstack-discuss@lists.openstack.org' <openstack-discuss@lists.openstack.org>
Subject: RE: openstack-discuss Digest, Vol 62, Issue 5 Netwok Configuration Isssue | Urgent

Hi openstack community,

I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses from the assigned networks which I have created provider and self-service flat network type. Hence, I may not be able to ping and ssh instance from the controller node and these instances won’t be able to connect to the internet. 

Can anyone guide me how to resolve this issue by pinpointing the initial network configurations settings.

-----Original Message-----
From: openstack-discuss-request@lists.openstack.org <openstack-discuss-request@lists.openstack.org>
Sent: Tuesday, December 5, 2023 9:30 PM
To: openstack-discuss@lists.openstack.org
Subject: openstack-discuss Digest, Vol 62, Issue 5

Send openstack-discuss mailing list submissions to
	openstack-discuss@lists.openstack.org

To subscribe or unsubscribe via email, send a message with subject or body 'help' to
	openstack-discuss-request@lists.openstack.org

You can reach the person managing the list at
	openstack-discuss-owner@lists.openstack.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..."

Today's Topics:

   1. Re: [Neutron] - Getting bridge_name of the port from Java sdk
      (smooney@redhat.com)
   2. Re: [cinder][nova][glance][ironic] restricting image metadata values to 255 chars
      (Jorge Merlino)
   3. [nova] Spec review day is TOMORROW (Sylvain Bauza)

----------------------------------------------------------------------

Message: 1
Date: Tue, 05 Dec 2023 11:41:06 +0000
From: smooney@redhat.com
Subject: Re: [Neutron] - Getting bridge_name of the port from Java sdk
To: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Cc: Mahudeeswaran Palanisamy <mahudees@gmail.com>,
	openstack-discuss@lists.openstack.org
Message-ID:
	<dc8b7b75904590a3124212668e89129080e3aaf9.camel@redhat.com>
Content-Type: text/plain; charset="UTF-8"

On Tue, 2023-12-05 at 11:53 +0100, Rodolfo Alonso Hernandez wrote:
...
Ok, I'll raise this issue in the Neutron team today during the 
networking meeting.
just to be clear we have not deprecated the options in nova yet i have been to busy with other work so we wont be removing this in nova in the near term.
i may propose a depercation patch depending on your disucssion but we are in no rush.

long term however it would be preferabel if neutron alwasy told use what bridge to use and we nolonger had to keep the nova.conf and neutron.conf/ovsdb in sync to have this work.
...
On Tue, Dec 5, 2023 at 11:45 AM <smooney@redhat.com> wrote:
...
On Tue, 2023-12-05 at 09:04 +0100, Rodolfo Alonso Hernandez wrote:
...
Hello Sean:
The bridge name in the port VIF details was added for the VLAN 
aware VMs feature. [1] is the patch adding this functionality in 
Nova. This is also used with bridge type ports (for hybrid plug).
yes but we then asked for this to always be set so we coudl 
eventually remove our config options for this.
https://github.com/openstack/neutron/commit/995744c576503b1de90c922d
becf690ad49f244f
https://bugs.launchpad.net/neutron/+bug/1788009
this change is requried to eventualy allow live migration between 
ml2/ovs and ml2/ovn when using vlan networkign
https://lists.openstack.org/pipermail/openstack-dev/2018-August/1335
46.html
i have 0 time to accutually fix all th things to make that work 
generically sicne that would also like need use to make it work for geneve too.
...
But there is no requirement
to include the name of the OVS bridge in this dictionary and we 
are not doing that for any other directly attached ports, not in 
ML2/OVS nor in ML2/OVN. If Nova requires that, then it should be 
needed to create an RFE in Neutron to always include it.
we have discuss this in the past and asked that this alwasy be set 
for ml2/ovn and any other ml2 driver that manage ovs.
if ml2/ovs does not always set it even when trunk port are not used 
then
https://bugs.launchpad.net/neutron/+bug/1788009 hwas been regressed 
and we shoudl fix that.
Regards.
[1]https://review.opendev.org/c/openstack/nova/+/260700
On Mon, Dec 4, 2023 at 6:55 PM <smooney@redhat.com> wrote:
...
On Mon, 2023-12-04 at 16:13 +0100, Rodolfo Alonso Hernandez wrote:
...
Hello Mahudeeswaran:
This topic is being discussed in [1]. The patch [2] you are
referring to
is
not changing the previous code related to the mentioned 
parameter
"bridge
name". Please check [3].
Also consider that this value was populated when using Trunk 
ports,
to
store the Trunk bridge name created on the port description. 
In
ML2/OVN,
all ports are attached to the integration bridge (there is a
configuration
parameter to define the integration name bridge called 
"integration_bridge", that by default is "br-int").
just to be clear from a nova perspective i would expect the 
value to always be populated when ovn binds the prot normally.
nova may have config options for the default bridge name to use 
but we should not be relying on them. so as apart of the ml2/ovs 
to ml2/ovn migration the bridge_name
in
the port binding should get
update to the correct value for the current cloud.
we have not formally deprcated
...
but
we likely shold do that now that we can rely on neutron ml2 
backend
https://docs.openstack.org/nova/latest/configuration/config.html#neu
tron.ovs_bridge
that
...
supprot ovs always settign this.
...
Regards.
[1]
https://lists.openstack.org/archives/list/openstack-discuss@lists.op
enstack.org/thread/X4GT7LA523FZWJCGEF2IKTG7VF5WSZWK/
...
...
[2]
https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e
49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd
604f9581d90f2985bb
...
...
[3]
https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e
49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd
604f9581d90f2985bbR33
...
...
On Mon, Dec 4, 2023 at 3:50 PM Mahudeeswaran Palanisamy <
mahudees@gmail.com>
...
wrote:
...
Hi All,
Looks like as part of the below commit, bridge_name info has 
been removed from port binding vif_details dictionary. Is 
there any way that we can get the bridge_name info of a port?
As far as checked we can get this info by checking if port 
UUID is part of the “ports” array in “sudo ovs-vsctl list 
br” output. But there is no equivalent way to get from Java SDK.
https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e
49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd
604f9581d90f2985bb
...
...
...
Thanks,
Mahudees
------------------------------

Message: 2
Date: Tue, 5 Dec 2023 13:27:49 -0300
From: Jorge Merlino <jorge.merlino@canonical.com>
Subject: Re: [cinder][nova][glance][ironic] restricting image metadata
	values to 255 chars
To: Erno Kuvaja <ekuvaja@redhat.com>
Cc: OpenStack Discuss <openstack-discuss@lists.openstack.org>
Message-ID: <4da4c94e-81bf-4660-887b-53c2a00e25f4@canonical.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 30/11/23 19:34, Erno Kuvaja wrote:
...
On Thu, 30 Nov 2023 at 20:55, Jorge Merlino 
<jorge.merlino@canonical.com <mailto:jorge.merlino@canonical.com>> wrote:
Hello stackers,
It has come to our attention recently that nova, cinder, and glance
    treat image properties differently. This came up in a discussion on a
    patch to extend the allowable length of image metadata values in
    cinder [0].
Briefly:
- glance allows image property values to be unrestricted in the
    schema, but effectively limited to 65535 bytes by the database.
- cinder restricts the length of an image property value to 255
    chars
    (by request schema) if you try to update the volume_image_properties on
    a volume, but if you create a volume from an image, cinder happily
    copies over all the image properties from glance, giving them an
    effective limit of 65535 bytes.
- nova mostly truncates image properties values to 255 chars
    (it's a
    bit more complicated, but we can consider that to be nova's behavior
    for
    the purposes of this discussion).
(We're not sure what ironic does, but they're in the subject line as a
    consumer of images and volumes.)
Note that we're talking about metadata *values* here; the metadata keys
    are already restricted by charset to basically US-ASCII and 255 length.
    Values are allowed to be unicode.
The point of this email is that it would be good for the services to be
    consistent about image metadata values. Thus, we propose that all
    services should restrict image metadata values to 255 unicode
    characters. (Which is sort of happening already, but not
consistently.)
The further point of this email is to find out what the impact of this
    restriction would be on current users. So please respond if you have a
    use case that would be affected by this change, and could not be
    addressed by, for example, instead of having one enormous value for a
    single key, the metadata was broken into a number of key/value pairs
    that would satisfy the 255 char restriction.
Thanks for your attention to this!
[0] https://review.opendev.org/c/openstack/cinder/+/868485
    <https://review.opendev.org/c/openstack/cinder/+/868485>
Hi Jorge & all,
To be very frank here, this sounds like a nova problem and your 
approach to fix the issue in Cinder seemed to be sensible and 
generally accepted there.
The metadefs basic concepts are explained in [0], Compute defines 
subsection of that, all predefined metadefs can be found from [1]
The very arrogant and false claim from your patch reviews that Nova 
would define all image properties and that definition would limit it 
to
255 characters is, well, hilarious.
Even the field definitions in the code do not specify such max size 
for most of those properties Nova _expects_ it might see and knows how 
to use, like Sean pointed out, it just happens to be limited how much 
of that Nova is able to store in their own database due to the field 
restriction at their DB layer. Lots of them properties are things like 
booleans or enumerations of values for Nova and thus have practical 
limitations. There are also fields like ListOfStrings, no max length 
defined.
Restricting the image properties from all the other consumers because 
Nova can't handle storing the copies of them, and thus breaking the 
Images API v2 and any use cases that uses image properties outside of 
Nova's fairly narrow scope would just be unacceptable. Either Nova 
should overcome their internal limitations and figure out how to deal 
with the resources or at very least understand to ignore them 
properties they have no capacity or interest handling.
Good luck and thanks for your patience to fight the windmills trying 
to get a simple fix in, Erno "jokke" Kuvaja
[0]
https://docs.openstack.org/glance/latest/user/metadefs-concepts.html
<https://docs.openstack.org/glance/latest/user/metadefs-concepts.html>
[1] https://github.com/openstack/glance/tree/master/etc/metadefs
<https://github.com/openstack/glance/tree/master/etc/metadefs>
I'll tend to agree with you, but I see some consistency problems from the user's point of view. For example, if they create a server from an image with long metadata values and then create an image (snapshot) from that server, the new image gets the same metadata parameters as the original image but truncated to 255 chars.

Thinking from the perspective of a Openstack user (that does not care what particular service implements what) it would be nice if there was some kind of global policy regarding this. As the shortest length supported right now is nova's, a simple (but maybe not the best?) solution would be to adapt to that length everywhere.

Regards
Jorge

------------------------------

Message: 3
Date: Tue, 5 Dec 2023 17:21:49 +0100
From: Sylvain Bauza <sbauza@redhat.com>
Subject: [nova] Spec review day is TOMORROW
To: OpenStack Discuss <openstack-discuss@lists.openstack.org>
Message-ID:
	<CALOCmumwKP9ifF10P91QZP4AkbyybBZAjnxAPaZCkVW=LHRRzA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="0000000000005bff15060bc5a231"

Hi folks,
We'll run our second spec review day tomorrow. Please make sure that your specs are online and in a reviewable state if you want us to look at them.
Please also check your Gerrit emails or be around on IRC in case we have any questions.

Cores, you know your duty.

Thanks,
-Sylvain

RE: openstack-discuss Digest, Vol 62, Issue 5 Netwok Configuration Isssue | Urgent

Asma Naz Shariq

tags

participants (1)