[Yahoo-eng-team] [Bug 1327473] Re: Don't use mutables as default args
** Also affects: octavia Importance: Undecided Status: New ** Changed in: octavia Assignee: (unassigned) => Bertrand Lallau (bertrand-lallau) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1327473 Title: Don't use mutables as default args Status in Cinder: Fix Released Status in heat: Fix Released Status in neutron: In Progress Status in OpenStack Compute (nova): Fix Released Status in octavia: New Status in oslo.messaging: Fix Released Status in python-heatclient: Fix Released Bug description: Passing mutable objects as default args is a known Python pitfall. We'd better avoid this. This is an example show the pitfall: http://docs.python-guide.org/en/latest/writing/gotchas/ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1327473/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511634] [NEW] "network address" is not marked with '*' in create subnet
Public bug reported: In project -> network, click "create network",then show a workflow. In that workflow's subnet tab,"network address " is marked with "*";But in network's details view, click "create subnet", "network address " is not marked with "*" in subnet tab ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1511634 Title: "network address" is not marked with '*' in create subnet Status in OpenStack Dashboard (Horizon): New Bug description: In project -> network, click "create network",then show a workflow. In that workflow's subnet tab,"network address " is marked with "*";But in network's details view, click "create subnet", "network address " is not marked with "*" in subnet tab To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1511634/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1270192] Re: cinder volume hanging on removing snapshots
Nova has the same issue with local lvm block storage:
http://logs.openstack.org/80/237480/8/check/gate-tempest-dsvm-
full/96d1bff/logs/screen-n-cpu.txt.gz?level=TRACE
** Also affects: nova
Importance: Undecided
Status: New
** Tags added: volumes
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1270192
Title:
cinder volume hanging on removing snapshots
Status in Cinder:
Fix Released
Status in Cinder icehouse series:
Fix Released
Status in OpenStack Compute (nova):
New
Bug description:
On any lvm2 version without lvmetad running, I can get cinder-volume
to hang on issuing lvm related commands after deleting snapshots (that
are non-thin provisioned LVM snapshots with clear_volume set to zero).
the issue is that lvm locks up due to trying to access suspended device
mapper entries, and at some point cinder-volume does a lvm related command and
hangs on that. a setting of ignore_suspended_devices = 1 in lvm.conf helps with
that, as lvremove hangs on scanning the device state (which it
needs to do because it doesn't have current information available via
lvmetad).
I can use this script to trigger the issue:
=== cut hang.sh ===
enable_fix=1
#enable_fix=0
vg=cinder-volumes
v=testvol.$$
lvcreate --name $v $vg -L 1g
sleep 2
lvcreate --name snap-$v --snapshot $vg/$v -L 1g
vgp=/dev/mapper/${vg/-/--}-snap--${v/-/--}
sleep 2
( sleep 10 < $vgp-cow ) &
test "$enable_fix" -eq "1" && lvchange -y -an $vg/snap-$v
lvremove -f $vg/snap-$v
sleep 1
lvremove -f $vg/$v
=== cut hang.sh ===
vg needs to be set to a lvm VG that exists and can take a few gig of
space. whenever enable_fix is set to 0, lvremove -f ends with :
Unable to deactivate open cinder--volumes-snap--testvol.27700-cow (252:5)
Failed to resume snap-testvol.27700.
libdevmapper exiting with 1 device(s) still suspended.
this is because the sleep command before keeps a fd open on the -cow.
The script then also never finishes and any other lvm command hangs as
well.
apparently in real-life this is either udev or the dd command still
having the fd open for some reason I have not yet understood.
The deactivation before removing seems to help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1270192/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511879] [NEW] Integration_tests: id_pattern not working for instances secondary row actions
Public bug reported:
id_pattern not working for instances secondary row actions
in regions->tables.py under the class ComplexActionRowRegion
id_patterns are handled by "src_elem.get_attribute('id')" which works
fine for other page table, row actions but not for Instances.
The cause is, "src_elem.get_attribute('id')" returns
"instances__row__2665f131-01cc-48ca-aa68-c0c823d6b292" instead of
"instances__row_2665f131-01cc-48ca-aa68-c0c823d6b292"
The diff is "row__", the correct id value is "row_", this could be
handled by string.replace()
** Affects: horizon
Importance: Undecided
Assignee: Amogh (amogh-r-mavinagidad)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1511879
Title:
Integration_tests: id_pattern not working for instances secondary row
actions
Status in OpenStack Dashboard (Horizon):
In Progress
Bug description:
id_pattern not working for instances secondary row actions
in regions->tables.py under the class ComplexActionRowRegion
id_patterns are handled by "src_elem.get_attribute('id')" which works
fine for other page table, row actions but not for Instances.
The cause is, "src_elem.get_attribute('id')" returns
"instances__row__2665f131-01cc-48ca-aa68-c0c823d6b292" instead of
"instances__row_2665f131-01cc-48ca-aa68-c0c823d6b292"
The diff is "row__", the correct id value is "row_", this could be
handled by string.replace()
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1511879/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511862] [NEW] Bandit tests for Glance
Public bug reported: Add automated tests for Glance using Bandit. Keystone has Bandit support, and can be used as a basis for support in Glance. https://github.com/openstack/keystone/blob/master/bandit.yaml#L31 ** Affects: glance Importance: Undecided Assignee: Drew Varner (avarner) Status: New ** Changed in: glance Assignee: (unassigned) => Drew Varner (avarner) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1511862 Title: Bandit tests for Glance Status in Glance: New Bug description: Add automated tests for Glance using Bandit. Keystone has Bandit support, and can be used as a basis for support in Glance. https://github.com/openstack/keystone/blob/master/bandit.yaml#L31 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1511862/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1270192] Re: cinder volume hanging on removing snapshots
** No longer affects: nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1270192
Title:
cinder volume hanging on removing snapshots
Status in Cinder:
Fix Released
Status in Cinder icehouse series:
Fix Released
Bug description:
On any lvm2 version without lvmetad running, I can get cinder-volume
to hang on issuing lvm related commands after deleting snapshots (that
are non-thin provisioned LVM snapshots with clear_volume set to zero).
the issue is that lvm locks up due to trying to access suspended device
mapper entries, and at some point cinder-volume does a lvm related command and
hangs on that. a setting of ignore_suspended_devices = 1 in lvm.conf helps with
that, as lvremove hangs on scanning the device state (which it
needs to do because it doesn't have current information available via
lvmetad).
I can use this script to trigger the issue:
=== cut hang.sh ===
enable_fix=1
#enable_fix=0
vg=cinder-volumes
v=testvol.$$
lvcreate --name $v $vg -L 1g
sleep 2
lvcreate --name snap-$v --snapshot $vg/$v -L 1g
vgp=/dev/mapper/${vg/-/--}-snap--${v/-/--}
sleep 2
( sleep 10 < $vgp-cow ) &
test "$enable_fix" -eq "1" && lvchange -y -an $vg/snap-$v
lvremove -f $vg/snap-$v
sleep 1
lvremove -f $vg/$v
=== cut hang.sh ===
vg needs to be set to a lvm VG that exists and can take a few gig of
space. whenever enable_fix is set to 0, lvremove -f ends with :
Unable to deactivate open cinder--volumes-snap--testvol.27700-cow (252:5)
Failed to resume snap-testvol.27700.
libdevmapper exiting with 1 device(s) still suspended.
this is because the sleep command before keeps a fd open on the -cow.
The script then also never finishes and any other lvm command hangs as
well.
apparently in real-life this is either udev or the dd command still
having the fd open for some reason I have not yet understood.
The deactivation before removing seems to help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1270192/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511707] [NEW] Updating ips for port incorrectly pass port dict in pluggable IPAM
Public bug reported: _ipam_allocate_ips expects to receive port dict as a third argument, but 'changes' are passed instead [1]. This issue do not lead to any misbehaviour for reference IPAM driver, because port dict is not used in default AddressRequestFactory[2]. Port dict in IPAM interface is expected to be used in custom AddressRequestFactory, that allows to create specific address requests based on port dict info. Found this bug during implementing custom AddressRequestFactory for Infoblox IPAM Driver. Affects: This issue affects only third-party vendors who implements own IPAM driver with custom AddressRequestFactory and uses port dict in it. [1] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_pluggable_backend.py#L287 [2] https://github.com/openstack/neutron/blob/master/neutron/ipam/requests.py#L258 ** Affects: neutron Importance: Undecided Assignee: Pavel Bondar (pasha117) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Pavel Bondar (pasha117) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1511707 Title: Updating ips for port incorrectly pass port dict in pluggable IPAM Status in neutron: In Progress Bug description: _ipam_allocate_ips expects to receive port dict as a third argument, but 'changes' are passed instead [1]. This issue do not lead to any misbehaviour for reference IPAM driver, because port dict is not used in default AddressRequestFactory[2]. Port dict in IPAM interface is expected to be used in custom AddressRequestFactory, that allows to create specific address requests based on port dict info. Found this bug during implementing custom AddressRequestFactory for Infoblox IPAM Driver. Affects: This issue affects only third-party vendors who implements own IPAM driver with custom AddressRequestFactory and uses port dict in it. [1] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_pluggable_backend.py#L287 [2] https://github.com/openstack/neutron/blob/master/neutron/ipam/requests.py#L258 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1511707/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511913] [NEW] set field's required attribute with 'data-is-required': 'true', isn't effective
Public bug reported:
in file /dashboards/admin/networks/forms.py, code like this:
segmentation_id = forms.IntegerField(
label=_("Segmentation ID"),
widget=forms.TextInput(attrs={
'class': 'switched',
'data-switch-on': 'network_type',
'data-network_type-vlan': _('Segmentation ID'),
'data-network_type-gre': _('Segmentation ID'),
'data-network_type-vxlan': _('Segmentation ID')
}))
then, in form, "Segmentation ID" is maked with '*',but modify the code like
this:
segmentation_id = forms.IntegerField(
label=_("Segmentation ID"),
required=False,
widget=forms.TextInput(attrs={
'class': 'switched',
'data-is-required': 'true',
'data-switch-on': 'network_type',
'data-network_type-vlan': _('Segmentation ID'),
'data-network_type-gre': _('Segmentation ID'),
'data-network_type-vxlan': _('Segmentation ID')
}))
in form,"Segmentation ID" isn't maked with '*'
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1511913
Title:
set field's required attribute with 'data-is-required': 'true',isn't
effective
Status in OpenStack Dashboard (Horizon):
New
Bug description:
in file /dashboards/admin/networks/forms.py, code like this:
segmentation_id = forms.IntegerField(
label=_("Segmentation ID"),
widget=forms.TextInput(attrs={
'class': 'switched',
'data-switch-on': 'network_type',
'data-network_type-vlan': _('Segmentation ID'),
'data-network_type-gre': _('Segmentation ID'),
'data-network_type-vxlan': _('Segmentation ID')
}))
then, in form, "Segmentation ID" is maked with '*',but modify the code like
this:
segmentation_id = forms.IntegerField(
label=_("Segmentation ID"),
required=False,
widget=forms.TextInput(attrs={
'class': 'switched',
'data-is-required': 'true',
'data-switch-on': 'network_type',
'data-network_type-vlan': _('Segmentation ID'),
'data-network_type-gre': _('Segmentation ID'),
'data-network_type-vxlan': _('Segmentation ID')
}))
in form,"Segmentation ID" isn't maked with '*'
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1511913/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1325684] Re: Launch Instance dialog - "nic" should probably be capitalized on the Networking tab
** Changed in: openstack-i18n Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1325684 Title: Launch Instance dialog - "nic" should probably be capitalized on the Networking tab Status in OpenStack Dashboard (Horizon): Fix Released Status in openstack i18n: Fix Released Bug description: On the Networking tab of the Launch Instance dialog, "nic" is all lowercase. Generally acronyms are capitalized. "nic" is used both for each interface, and in the description on the right pane. Somewhat related to that, on the same dialog and tab, we say "Selected Networks" and underneath that, "Available networks", which don't follow the same capitalization conventions. "Available Networks" would match what seems to be used elsewhere in the UI. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325684/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1317794] Re: Complete translations are too big
** Changed in: openstack-i18n Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1317794 Title: Complete translations are too big Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in openstack-api-site: Fix Released Status in openstack i18n: Fix Released Status in openstack-manuals: Fix Released Status in Sahara: Fix Released Status in Trove: Fix Released Bug description: From http://lists.openstack.org/pipermail/openstack- i18n/2014-May/000594.html: "I've come across this review for automated translations coming into Horizon https://review.openstack.org/#/c/91523/ It concerns me that it has over a half million LOC in it, and many of these languages have near 0 translation. (I checked here: https://www.transifex.com/projects/p/horizon/). 0 translation languages have just as many lines as full translations; they are just shorter." The proposal in the thread is: 1) Our translation jobs will only download files that have at least 75 % translated 2) Projects can delete (and I'm going to propose patches) files that currently have less than 75 % translated To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1317794/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1508786] Re: Request for Liberty release of networking-ofagent
Kyle, thank you for fixing this. ** Changed in: networking-ofagent Status: New => Fix Released ** Changed in: networking-ofagent Assignee: (unassigned) => fumihiko kakuma (kakuma) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1508786 Title: Request for Liberty release of networking-ofagent Status in networking-ofagent: Fix Released Status in neutron: Fix Released Bug description: This bug is to request the neutron-release team to tag and release for Liberty of networking-ofagent as Sub-Project Release Process. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-ofagent/+bug/1508786/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1255004] Re: I18n: Localization of the role "Member"
** Changed in: openstack-i18n Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1255004 Title: I18n: Localization of the role "Member" Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) havana series: Fix Released Status in openstack i18n: Fix Released Bug description: Hi, There is a very strange thing happened to role "Member" when I set Horizon to use my local language. In the dialog "Domain Groups", it is translated. But in the dialog of "Project Members" and "Project Groups", it is not translated. From my point of view, if we can localize role names, it will be wonderful. If we are not able to localize role names, it is acceptable. But we need to make them consistent. Hope somebody can take a look at this interested issue. Thanks. Daisy To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1255004/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511732] [NEW] HA router schedule for another active agent
Public bug reported: Neutron Liberty, Ubuntu 14.04 3 controllers(3 l3-agents are available and active.), 1 compute I have max_l3_agents_per_router=2, router is scheduled to 2 agents. If you of one these agents is stopped I will have something like: root@node-1:~# neutron l3-agent-list-hosting-router r3 +--+---++---+--+ | id | host | admin_state_up | alive | ha_state | +--+---++---+--+ | 1fa93569-fc36-4fb4-b467-85b11ba5f20c | node-3.domain.tld | True | xxx | active | | 709998f7-cc64-4b6a-9777-6c815dfebb5c | node-2.domain.tld | True | :-) | active | +--+---++---+--+ The point is: router won't be rescheduled from dead agent and scheduled for another available active one. This situation can be avoided by simply setting max_l3_agents_per_router=0, but for current case is it possible to have a solution? ** Affects: neutron Importance: Undecided Assignee: Ann Kamyshnikova (akamyshnikova) Status: New ** Tags: l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1511732 Title: HA router schedule for another active agent Status in neutron: New Bug description: Neutron Liberty, Ubuntu 14.04 3 controllers(3 l3-agents are available and active.), 1 compute I have max_l3_agents_per_router=2, router is scheduled to 2 agents. If you of one these agents is stopped I will have something like: root@node-1:~# neutron l3-agent-list-hosting-router r3 +--+---++---+--+ | id | host | admin_state_up | alive | ha_state | +--+---++---+--+ | 1fa93569-fc36-4fb4-b467-85b11ba5f20c | node-3.domain.tld | True | xxx | active | | 709998f7-cc64-4b6a-9777-6c815dfebb5c | node-2.domain.tld | True | :-) | active | +--+---++---+--+ The point is: router won't be rescheduled from dead agent and scheduled for another available active one. This situation can be avoided by simply setting max_l3_agents_per_router=0, but for current case is it possible to have a solution? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1511732/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511722] [NEW] VM loses connectivity on floating ip association when using l3_ha
Public bug reported: I not sure if my issue is related to this bug https://bugs.launchpad.net/neutron/+bug/1389880, it's new one or it's a misconfiguration, but I have the same symptoms. If I create a new router in HA ( # neutron router-create --ha=True router01), everything works fine. When I create a new router without HA flag, if I have an instance with one floating IP and then I assign a floating IP to other instance, I lose external connectivity to both instance (doesn't matter the number of instances, I lose external connectivity with all of them) until I connect to anyone by vnc and I ping to external/internet IP, and then everything works fine again. Sorry, English is not my native language. Ubuntu 14.04 Open vSwitch 2.3.2 Kilo 2015.1.1 root@network01:/home/administrator# cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^# [DEFAULT] verbose = False rpc_backend = rabbit auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True dhcp_agents_per_network = 2 l3_ha = True max_l3_agents_per_router = 2 min_l2_agents_per_router = 2 [matchmaker_redis] [matchmaker_ring] [quotas] [agent] root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf [keystone_authtoken] auth_uri = http://10.8.11.120:5000 auth_url = http://10.8.11.120:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = neutron password = secret [database] [nova] [oslo_concurrency] lock_path = $state_path/lock [oslo_policy] [oslo_messaging_amqp] [oslo_messaging_qpid] [oslo_messaging_rabbit] rabbit_hosts = controller01:5672,controller02:5672 rabbit_userid = openstack rabbit_password = secret rabbit_retry_interval = 1 rabbit_retry_backoff = 2 rabbit_max_retries = 0 rabbit_durable_queues = True rabbit_ha_queues = True root@network01:/home/administrator# cat /etc/neutron/l3_agent.ini | grep -v ^$ | grep -v ^# [DEFAULT] verbose = True interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver external_network_bridge = router_delete_namespaces = True root@network01:/home/administrator# cat /etc/neutron/plugins/ml2/ml2_conf.ini | grep -v ^$ | grep -v ^# [ml2] type_drivers = flat,vlan,gre,vxlan tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat] flat_networks = external [ml2_type_vlan] [ml2_type_gre] tunnel_id_ranges = 1:1000 [ml2_type_vxlan] [securitygroup] enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver [ovs] local_ip = 192.168.0.101 bridge_mappings = external:br-ex [agent] tunnel_types = gre root@compute01:/home/ubuntu# cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^# [DEFAULT] verbose = True rpc_backend = rabbit auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True [matchmaker_redis] [matchmaker_ring] [quotas] [agent] root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf [keystone_authtoken] auth_uri = http://10.8.11.120:5000 auth_url = http://10.8.11.120:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = neutron password = secret [database] [nova] [oslo_concurrency] lock_path = $state_path/lock [oslo_policy] [oslo_messaging_amqp] [oslo_messaging_qpid] [oslo_messaging_rabbit] rabbit_hosts = controller01:5672,controller02:5672 rabbit_userid = openstack rabbit_password = secret rabbit_retry_interval = 1 rabbit_retry_backoff = 2 rabbit_max_retries = 0 rabbit_durable_queues = True rabbit_ha_queues = True root@compute01:/home/ubuntu# cat /etc/neutron/plugins/ml2/ml2_conf.ini | grep -v ^$ | grep -v ^# [ml2] type_drivers = flat,vlan,gre,vxlan tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat] [ml2_type_vlan] [ml2_type_gre] tunnel_id_ranges = 1:1000 [ml2_type_vxlan] [securitygroup] enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver [ovs] local_ip = 192.168.0.105 [agent] tunnel_types = gre ** Affects: neutron Importance: Undecided Status: New ** Tags: kilo neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1511722 Title: VM loses connectivity on floating ip association when using l3_ha Status in neutron: New Bug description: I not sure if my issue is related to this bug https://bugs.launchpad.net/neutron/+bug/1389880, it's new one or it's a misconfiguration, but I have the same symptoms. If I create a new router in HA ( # neutron router-create --ha=True router01), everything works fine. When I create a new router without HA flag, if I have an instance with one floating IP and then I assign a floating IP to other instance, I lose external connectivity to both instance (doesn't matter the number of instances, I lose
[Yahoo-eng-team] [Bug 1476770] Re: _translate_from_glance fails with "AttributeError: id" in grenade
Finding same problem while using stable/kilo magnum (bay-create). This is due to glance-show returning id when using (--os-image-api- version 1). Using --os-image-api-version 2 fixes the issue. ** Also affects: python-magnumclient (Suse) Importance: Undecided Status: New ** No longer affects: python-magnumclient (Suse) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1476770 Title: _translate_from_glance fails with "AttributeError: id" in grenade Status in Glance: Invalid Status in openstack-ansible: In Progress Status in OpenStack-Gate: Fix Committed Status in oslo.vmware: Fix Released Status in python-glanceclient: New Bug description: http://logs.openstack.org/28/204128/2/check/gate-grenade- dsvm/80607dc/logs/old/screen-n-api.txt.gz?level=TRACE 2015-07-21 17:05:37.447 ERROR nova.api.openstack [req-9854210d-b9fc-47ff-9f00-1a0270266e2a tempest-ServersTestJSON-34270062 tempest-ServersTestJSON-745803609] Caught error: id 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack Traceback (most recent call last): 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/opt/stack/old/nova/nova/api/openstack/__init__.py", line 125, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return req.get_response(self.application) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317, in send 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack application, catch_exc_info=False) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1281, in call_application 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return resp(environ, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", line 634, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return self._call_app(env, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", line 554, in _call_app 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return self._app(env, _fake_start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return resp(environ, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return resp(environ, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/routes/middleware.py", line 136, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack response = self.app(environ, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return resp(environ, start_response) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/opt/stack/old/nova/nova/api/openstack/wsgi.py", line 756, in __call__ 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack content_type, body, accept) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/opt/stack/old/nova/nova/api/openstack/wsgi.py", line 821, in _process_stack 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack action_result = self.dispatch(meth, request, action_args) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File "/opt/stack/old/nova/nova/api/openstack/wsgi.py", line 911, in dispatch 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack return method(req=request, **action_args) 2015-07-21 17:05:37.447 21251 TRACE nova.api.openstack File
[Yahoo-eng-team] [Bug 1491905] Re: neutronclient in nova doesn't issue new token
** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1491905 Title: neutronclient in nova doesn't issue new token Status in OpenStack Compute (nova): Fix Released Bug description: neutronclient in nova uses token_endpoint.Token as auth_plugin, which doesn't have functionality to re-authenticate in case of 401 error. If keystone uses memcached as backend and it was restarted, token that neutronclient use become invalid, and no re-authentication attempts were made. Trace in nova-api: 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/nova/network/neutronv2/api.py", line 1519, in _build_network_info_model 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] data = client.list_ports(**search_opts) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 102, in with_params 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] ret = self.function(instance, args, *kwargs) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 534, in list_ports 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] **_params) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 307, in list 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] for r in self._pagination(collection, path, **params): 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 320, in _pagination 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] res = self.get(path, params=params) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 293, in get 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] headers=headers, params=params) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 270, in retry_request 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] headers=headers, params=params) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 211, in do_request 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] self._handle_fault_response(status_code, replybody) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 185, in _handle_fault_response 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] exception_handler_v20(status_code, des_error_body) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 83, in exception_handler_v20 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] message=message) 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] NeutronClientException: Authentication required 2015-08-30 19:02:24.292 8914 TRACE nova.network.base_api [instance: 94ccc989-4531-43a9-a1bd-d7cf848f04a8] To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491905/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1175211] Re: quantum DNS name does not match VM hostname
Sorry I meant this one: https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution ** Changed in: neutron Status: Confirmed => Fix Released ** Changed in: neutron Assignee: Dariusz Smigiel (smigiel-dariusz) => Miguel Lavalle (minsel) ** No longer affects: nova -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1175211 Title: quantum DNS name does not match VM hostname Status in neutron: Fix Released Bug description: Using Networking DHCP agent, cloud-init and Nova metadata, we're seeing a situation where the VM hostname does not match the DNS name. This causes things like 'sudo' to complain and 'hostname -f' to fail on the VM, and represents a regression from existing nova-network behavior. An example of the problem and a potential solution are outlined below for comment. For example: $ nova list +--+-++---+ | ID | Name| Status | Networks | +--+-++---+ | 92a4075e-31a4-45e1-909d-f71ee4c55de4 | jvm44 | ACTIVE | jnet41=10.10.20.5| +--+-++---+ On the VM: ubuntu@jvm44:~$ hostname jvm44 ubuntu@jvm44:~$ hostname -f hostname: Temporary failure in name resolution ubuntu@jvm44:~$ sudo bash sudo: unable to resolve host jvm44 root@jvm44:~# Changing the hostname to match DNS name fixes the problem: ubuntu@10-10-20-5:~$ hostname 10-10-20-5 ubuntu@10-10-20-5:~$ hostname -f 10-10-20-5.openstacklocal ubuntu@10-10-20-5:~$ sudo bash root@10-10-20-5:~# The VM name in DNS is 10-10-20-5.openstacklocal. as seen here: root@jvm44:~# nslookup 10.10.20.5 Server: 10.10.20.2 Address: 10.10.20.2#53 5.20.10.10.in-addr.arpa name = 10-10-20-5.openstacklocal. While DNSaaS may be the eventual answer to this problem, there may be a simpler fix for the case where DNSaaS is not available. A potential, minimally invasive fix for this might be: 1) modify quantum/agent/linux/dhcp.py _output_hosts_file to set the DNS name from the port name (if port name is set and if it is a valid DNS name, otherwise set from fixed IP as currently done) 2) modify nova to set the port name to match the VM name To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1175211/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1506003] Re: openstack cannot add vlan for VF with ixgbe 4.1.2 automatically
Ok based on Paolo's feedback, I'll mark this invalid. ** Changed in: neutron Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1506003 Title: openstack cannot add vlan for VF with ixgbe 4.1.2 automatically Status in neutron: Invalid Bug description: Summary: For support sr-iov, add port attribute 'binding:vnic_type: direct', after create the VM, found openstack can't add vlan tag to VF port(ixgbe 4.1.2) automatically Description: network vlan is 630, use openstack(kilo) to create VM, when use the ixgbe driver 4.0.1-k-rh7.1,then I can see the VF port, and VM can access the public network, vf 0 MAC fa:16:3e:a8:82:dd, vlan 630, spoof checking on, link-state auto but when change driver to 4.1.2, same operation, can't find the vlan, VM can't access the public network vf 12 MAC fa:16:3e:f5:2c:b8, spoof checking on, link-state auto if I use the "ip link set eth0 vf 12 vlan 630", it can work. we need use the driver 4.1.2, so how to let openstack add vlan automatically? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1506003/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511748] [NEW] Adding new security group rule Custom ICMP rule has wrong error messages
Public bug reported: When adding new rules to 'default' security group. When trying to add new 'Custom ICMP rule', I am not able to select 'Type' as -1 and 'Code' as -1 as well. But the same works from the command line utility i.e. [$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0]. But the problem is the errors that are provided are wrong. Instead of 'wrong code' or 'wrong type' it says 'wrong port'. The exact info can be seen in snapshot at [1]. I am running this off a devstack single node instance. [1] http://ibin.co/2KphvtVSTrCV ** Affects: horizon Importance: Undecided Assignee: Suraj Deshmukh (surajssd009005) Status: New ** Attachment added: "This is the image which shows what the error is." https://bugs.launchpad.net/bugs/1511748/+attachment/4509308/+files/Screenshot%20from%202015-10-30%2019-21-39.png ** Changed in: horizon Assignee: (unassigned) => Suraj Deshmukh (surajssd009005) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1511748 Title: Adding new security group rule Custom ICMP rule has wrong error messages Status in OpenStack Dashboard (Horizon): New Bug description: When adding new rules to 'default' security group. When trying to add new 'Custom ICMP rule', I am not able to select 'Type' as -1 and 'Code' as -1 as well. But the same works from the command line utility i.e. [$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0]. But the problem is the errors that are provided are wrong. Instead of 'wrong code' or 'wrong type' it says 'wrong port'. The exact info can be seen in snapshot at [1]. I am running this off a devstack single node instance. [1] http://ibin.co/2KphvtVSTrCV To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1511748/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511782] [NEW] securitygroup rule and member updates not applied correctly
Public bug reported: Summary: When using enhanced RPC, the security group rules and members are updated after the call to update port filter. This is with a firewall driver that has no need to use defer_apply based implementation. Description: In class SecurityGroupAgentRpc(..) refresh_firewall, if we use enhanced_rpc, the rules and members are updated after the calls to update_port_filter (...). This works fine for IP Tables based firewall driver, since it has the need to override 'filter_defer_apply_on' and 'filter_defer_apply_off' methods to defer calling of iptables cmds. Due to this, Firewall drivers that do not override filter_defer_apply_on/off methods misses applying the new rules, since rule updates happens post update_port_filter call into the driver. Symptoms: Rule update or a security group member update is not processed by the firewall driver instantly. Environment: Openstack master with hyper-v security groups driver with enhanced_rpc set to True. This is applicable to any Firewall driver that chooses not to implement defer_apply* related methods. ** Affects: neutron Importance: Undecided Assignee: Sonu (sonu-sudhakaran) Status: New ** Changed in: neutron Assignee: (unassigned) => Sonu (sonu-sudhakaran) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1511782 Title: securitygroup rule and member updates not applied correctly Status in neutron: New Bug description: Summary: When using enhanced RPC, the security group rules and members are updated after the call to update port filter. This is with a firewall driver that has no need to use defer_apply based implementation. Description: In class SecurityGroupAgentRpc(..) refresh_firewall, if we use enhanced_rpc, the rules and members are updated after the calls to update_port_filter (...). This works fine for IP Tables based firewall driver, since it has the need to override 'filter_defer_apply_on' and 'filter_defer_apply_off' methods to defer calling of iptables cmds. Due to this, Firewall drivers that do not override filter_defer_apply_on/off methods misses applying the new rules, since rule updates happens post update_port_filter call into the driver. Symptoms: Rule update or a security group member update is not processed by the firewall driver instantly. Environment: Openstack master with hyper-v security groups driver with enhanced_rpc set to True. This is applicable to any Firewall driver that chooses not to implement defer_apply* related methods. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1511782/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511775] [NEW] Revoking a role revokes the unscoped token for a user
Public bug reported: In Juno and Kilo, when a role is revoked from a user on a project, a callback is triggered that invalidates all of that user's tokens. I can see why we'd want to do that for scoped tokens. But by revoking the unscoped token as well, the user is forced to log out and log back in. It seems like the unscoped token should be left alone, since revoking a role is an authorization change, and the unscoped token is an authentication issue. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1511775 Title: Revoking a role revokes the unscoped token for a user Status in OpenStack Identity (keystone): New Bug description: In Juno and Kilo, when a role is revoked from a user on a project, a callback is triggered that invalidates all of that user's tokens. I can see why we'd want to do that for scoped tokens. But by revoking the unscoped token as well, the user is forced to log out and log back in. It seems like the unscoped token should be left alone, since revoking a role is an authorization change, and the unscoped token is an authentication issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1511775/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1506244] Re: support SSH key value over fingerprint for Azure
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Vivid) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Trusty) Importance: Undecided Status: New ** Summary changed: - support SSH key value over fingerprint for Azure + [SRU] support SSH key value over fingerprint for Azure ** Description changed: - Azure is changing the ovf-env.xml file. Instead of passing a fingerprint - to the key and obtaining it separately, the SSH public key itself is - passed via a new "" parameters: + SRU JUSTIFICATION - - - - EB0C0AB4B2D5FC35F2F0658D19F44C8283E2DD62 - $HOME/UserName/.ssh/authorized_keys - ssh-rsa NOTAREALKEY== foo@bar.local - - + [BACKGROUND] Azure's meta-data source now supports the use of SSH key + values in addition to fingerprints. + + [IMPACT] Instances booted with out cloud-init support for SSH public key + values will be inaccessable on boot via SSH. + + [FIX] Backport of 15.10 SSH public key support. Starting with 15.10, + cloud-init supports both values (preferred) or generating the SSH public + key from a fingerprint. + + [TEST CASE] + - Update cloud-init from proposed + - Capture instance + - Create instance using SSH fingerprint, confirm instance is accessible via SSH. + - Create instance using SSH public key value, confirm instance is accessible via SSH. + - Create instance using both SSH fingerprint and a different SSH public key value. Confirm that the instance is accessible via SSH only with SSH public key value (i.e. the fingerprint is ignored). + + + [ORIGINAL REPORT] + Azure is changing the ovf-env.xml file. Instead of passing a fingerprint to the key and obtaining it separately, the SSH public key itself is passed via a new "" parameters: + + + + + EB0C0AB4B2D5FC35F2F0658D19F44C8283E2DD62 + $HOME/UserName/.ssh/authorized_keys + ssh-rsa NOTAREALKEY== foo@bar.local + + ** Changed in: cloud-init Status: New => Fix Released ** Changed in: cloud-init (Ubuntu) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Precise) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Trusty) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Vivid) Status: New => In Progress ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: In Progress ** Also affects: cloud-init (Ubuntu Wily) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Wily) Status: New => Fix Released ** Changed in: cloud-init (Ubuntu Xenial) Status: In Progress => Fix Released ** Changed in: cloud-init (Ubuntu Xenial) Assignee: (unassigned) => Ben Howard (utlemming) ** Changed in: cloud-init (Ubuntu Wily) Assignee: (unassigned) => Ben Howard (utlemming) ** Changed in: cloud-init (Ubuntu Vivid) Assignee: (unassigned) => Ben Howard (utlemming) ** Changed in: cloud-init (Ubuntu Trusty) Assignee: (unassigned) => Ben Howard (utlemming) ** Changed in: cloud-init (Ubuntu Precise) Assignee: (unassigned) => Ben Howard (utlemming) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1506244 Title: [SRU] support SSH key value over fingerprint for Azure Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: In Progress Status in cloud-init source package in Trusty: In Progress Status in cloud-init source package in Vivid: In Progress Status in cloud-init source package in Wily: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: SRU JUSTIFICATION [BACKGROUND] Azure's meta-data source now supports the use of SSH key values in addition to fingerprints. [IMPACT] Instances booted with out cloud-init support for SSH public key values will be inaccessable on boot via SSH. [FIX] Backport of 15.10 SSH public key support. Starting with 15.10, cloud-init supports both values (preferred) or generating the SSH public key from a fingerprint. [TEST CASE] - Update cloud-init from proposed - Capture instance - Create instance using SSH fingerprint, confirm instance is accessible via SSH. - Create instance using SSH public key value, confirm instance is accessible via SSH. - Create instance using both SSH fingerprint and a different SSH public key value. Confirm that the instance is accessible via SSH only with SSH public key value (i.e. the fingerprint is ignored). [ORIGINAL REPORT] Azure is changing
[Yahoo-eng-team] [Bug 1511790] [NEW] Quickstart guide says to update environment_version which does not exist
Public bug reported: The horizon quickstart guide has an important note that tells the developer to update the environment_version variable in the run_tests.sh file whenever they change something in the environment [1]. The problem is this variable no longer exists [2]. [1] http://docs.openstack.org/developer/horizon/quickstart.html#horizon-s-structure [2] https://review.openstack.org/119842 ** Affects: horizon Importance: Undecided Assignee: Syed Ahsan Shamim Zaidi (ahsanmohsin04) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1511790 Title: Quickstart guide says to update environment_version which does not exist Status in OpenStack Dashboard (Horizon): New Bug description: The horizon quickstart guide has an important note that tells the developer to update the environment_version variable in the run_tests.sh file whenever they change something in the environment [1]. The problem is this variable no longer exists [2]. [1] http://docs.openstack.org/developer/horizon/quickstart.html#horizon-s-structure [2] https://review.openstack.org/119842 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1511790/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1191960] Re: force-delete of cinder volume errors with Can\'t remove open logical volume
Nova has similar issues with local lvm block storage: http://logs.openstack.org/80/237480/8/check/gate-tempest-dsvm- full/96d1bff/logs/screen-n-cpu.txt.gz?level=TRACE ** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova Status: New => Confirmed ** Changed in: nova Assignee: (unassigned) => Matt Riedemann (mriedem) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1191960 Title: force-delete of cinder volume errors with Can\'t remove open logical volume Status in Cinder: Fix Released Status in OpenStack Compute (nova): Confirmed Bug description: As a consequence of Bug #1191431, few volumes were left in error_deleting state. Few of the cleared off by issuing cinder delete , however few of the errored out. 1.When you try deleting such volume from Horizon > volume > check box > Delete Volumes Error: You do not have permission to delete volume: 2.When you try using 'Force Delete Volume' option against the suspected volume. The request gets submitted successfully, however you will see following error messages in /var/log/cinder/cinder-volume on the controller node: ProcessExecutionError: Unexpected error while running command. Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf lvremove -f cinder-volumes/volume-078cd44b-7b39-4867-a1e9-78bb758ae0a7 Exit code: 5 Stdout: ''Stderr: ' Can\'t remove open logical volume "volume-078cd44b-7b39-4867-a1e9-78bb758ae0a7"\n' 3.When you try delete manually through command line, you get the following error: lvremove -f /dev/cinder-volumes/volume-078cd44b-7b39-4867-a1e9-78bb758ae0a7 Can't remove open logical volume "volume-078cd44b-7b39-4867-a1e9-78bb758ae0a7" Workaround 1.The volume is left in in-use state by tgtd service that causes cinder delete and force-delete not to work. Stop the service that is using it: service tgt stop lvremove /dev/cinder-volumes/volume-078cd44b-7b39-4867-a1e9-78bb758ae0a7 2.Now, remove it through cinder-api or cli service tgt start cinder force-delete 078cd44b-7b39-4867-a1e9-78bb758ae0a7 Note: lsof /dev/cinder-volumes/volume-078cd44b- 7b39-4867-a1e9-78bb758ae0a7 reported tgtd using it. Expected behavior: force-delete option must address such anomalies. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1191960/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
