[Yahoo-eng-team] [Bug 1325472] [NEW] API not idempotent
Public bug reported: The API for creating an instance does not support idempotent usage. ** Affects: nova Importance: Undecided Status: New ** Tags: api conductor -- 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/1325472 Title: API not idempotent Status in OpenStack Compute (Nova): New Bug description: The API for creating an instance does not support idempotent usage. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1325472/+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 1324934] Re: port leak when instance is deleted before ACTIVE
** Description changed:
If an instance is deleted after it has a neutron port allocated but
before it has reached ACTIVE state, sometimes the port is not deleted
but the instance is. These orphan ports count toward the user's quota
so if it happens enough times the user will be unable to boot instances.
+
+ The same problem has been reported regarding hpcloud internal monitoring
+ tools, and the openstack-infra nodepool tenant. There seems to be a
+ port leak.
+
+ Evidence
+
+
+ Sometimes instances fail to boot with the following error:
+
+ 2014-05-27 00:09:23 ERROR : [NOV58] NovaServers.add Failed: OverLimit
+ - Maximum number of ports exceeded (HTTP 413) (Request-ID: req-
+ e05525c3-0876-4da4-8a81-8dcc3432b418)
+ args('('SLAM_META_m1_az1_00_09_NC_TEMP',
+ u'8c096c29-a666-4b82-99c4-c77dc70cfb40', u'100', 'metastmkey_m1_az1',
+ 'metastm_m1_az1', u'ee7d6d37-d855-4d30-a67b-0d88a03e72fc', 'az1'),{}')
+
+
+ Investigating further, starting with the neutron database:
+
+ mysql select * from ports where device_owner like 'comput%';
+
++--+-+--+---+++--+--+
+ | tenant_id | id | name| network_id
| mac_address | admin_state_up | status |
device_id| device_owner |
+
++--+-+--+---+++--+--+
+ | 27772649216983 | 00021f10-dcd7-4198-ae2b-d18b9410eb44 | |
a06ab43e-585f-4c32-8925-c903d79a5aaa | fa:16:3e:66:85:10 | 1 |
ACTIVE | 2f4e1412-6aed-4e28-ab0d-543a579a9796 | compute:az3 |
+ | 44971349524446 | 0027ffa0-97a3-4ad6-af75-36d6d0240ece | |
28200352-b51d-437d-a62b-0a47c1a85326 | fa:16:3e:d1:a8:05 | 1 |
ACTIVE | b7163835-3747-4f3b-8c5f-13ec17848743 | compute:az1 |
+ | 61149338019956 | 003843bf-09f4-4380-a161-719f01ff072c | |
862ed494-2dad-49d8-b2b1-ce5b03da5891 | fa:16:3e:c5:78:3a | 1 |
ACTIVE | 0ba0c1ad-5dac-4f0a-b9a7-9ee387a69dc8 | compute:az1 |
+ | 10578736914191 | 003cfa8d-8fab-4920-a0f0-7909ab789154 | |
a8784cc6-ee59-458b-ae39-6bcc081b58a6 | fa:16:3e:94:b0:e0 | 1 |
ACTIVE | 9cce27cf-f39c-432e-ae62-bc345cb6ef20 | compute:az2 |
+ | 60948452113939 | 0046cc65-67da-4606-a396-4de3e0b733aa | |
a03b1336-3144-4914-8354-4c1b093bff5c | fa:16:3e:9c:a2:54 | 1 |
ACTIVE | 25f9ebf5-cc5e-456f-9c87-221cfb68c88b | compute:az1 |
+ | 11382141558535 | 004fa94d-c5cc-4350-8d07-96b2b6fe6ed8 | |
c2c04cd5-1329-4707-ae23-c22777259702 | fa:16:3e:27:94:64 | 1 |
ACTIVE | 595dcdad-c426-474d-b613-5fe11949be27 | compute:az2 |
+ | 85660834569272 | 004fb569-2bff-4cf4-b1ee-ab1c7e7af3c5 | |
d202537d-d436-4226-85f6-70370b1971d1 | fa:16:3e:01:3d:3f | 1 |
ACTIVE | ef9e842a-4080-43ba-afd9-73ff3339f98b | compute:az1 |
+ | 61149338019956 | 005836cd-7bfc-48e7-a18b-17aea020f80f | |
862ed494-2dad-49d8-b2b1-ce5b03da5891 | fa:16:3e:e5:22:89 | 1 |
ACTIVE | 7560590b-0173-40a7-ba94-44d25fd6e8de | compute:az2 |
+ | 22067631723371 | 006686c9-ce05-4f1f-a649-238158e209f3 | |
55171400-916e-422c-9068-1de4ce3ebec2 | fa:16:3e:d6:02:30 | 1 |
ACTIVE | e64ef387-bae1-4321-adaa-9faa9db82c8b | compute:az2 |
+ | 10980441848524 | 006f1be3-f85a-4dfe-91f3-8540cada795b | krak|
85170ed0-a5b1-4e99-a033-56cb05a51d15 | fa:16:3e:e6:17:e5 | 1 |
ACTIVE | 2e5174ec-4255-432e-a3f8-d8ab3a21e9fa | compute:az1 |
+ | 10308385519040 | 0076afd8-a838-481f-9701-9a40d8eab25b | |
be9486e2-e179-48c7-bf1b-96e81ff1eb34 | fa:16:3e:a4:81:0a | 1 |
ACTIVE | 9a5f081c-a07b-4309-a9b6-715e1a9be859 | compute:az2 |
+ | 34809866885491 | 007ff0bf-c940-4a80-88ad-617dd46aba95 | |
76a0cdcb-22b2-4678-8466-8c959177c0a8 | fa:16:3e:de:ad:7b | 1 |
ACTIVE | e1a592fa-ee3e-4e02-8537-0eacf54b6d32 | compute:az2 |
+ | 10876451072196 | 00814bf0-1dfe-4c53-9664-cd69cd1a9213 | |
13444eee-2cf7-4051-acff-5347844697f8 | fa:16:3e:22:09:27 | 1 |
ACTIVE | 2e027d7e-1bed-4bcd-a347-b348ae4380ca | compute:az2 |
+ | 10075236746315 | 00910429-3d7b-4423-8b39-062a32d72c56 | |
048fe0df-4ff7-40d5-86f0-2bf9c56550c3 | fa:16:3e:87:69:4c | 1 |
ACTIVE | 6ed40a37-f49f-43e2-9935-86d054fec293 | compute:az2 |
+ | 53278391320577 | 009b9978-d6a8-4163-bfb7-75cb72c62d10 | |
6b98a3a7-60bc-4194-a7f3-32cd337821d3 | fa:16:3e:e1:24:ed | 1 |
ACTIVE | bee69220-2579-4c4b-9f45-5b321dd42de7 | compute:az2 |
+ | 10087549362244 | 00ad592f-577b-4434-ab7e-9970c06fcef1 | |
238df4ac-6140-4ae9-98d2-27db38c9d184 | fa:16:3e:3e:40:28 | 1 |
ACTIVE |
[Yahoo-eng-team] [Bug 1314313] Re: Firewall fails to become active within 300 seconds
Adding tempest. Adding short delay between operations in fwaas api test may help to avoid race ** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Status: New = Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1314313 Title: Firewall fails to become active within 300 seconds Status in OpenStack Neutron (virtual network service): Confirmed Status in Tempest: Confirmed Bug description: Upstream jobs are revealing that a FWaaS extension test is failing because the firewall does not become active within tempest's timeout (300 seconds). It seems the l3 agent receives the firewall create notification from the neutron server but then either the firewall is not processed or the notification not sent back to the neutron server. logstash: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVGltZWQgb3V0IHdhaXRpbmcgZm9yIGZpcmV3YWxsXCIgQU5EIG1lc3NhZ2U6XCJiZWNvbWUgQUNUSVZFXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjEzOTg3OTM2MTYxOTd9 This bug is being marked as critical because of 9 hits in the gate queue in the past 48 hours. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1314313/+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 1275695] Re: Enabling Federation extension causes Unregistered dependency: federation_api
** Changed in: keystone Status: In Progress = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1275695 Title: Enabling Federation extension causes Unregistered dependency: federation_api Status in OpenStack Identity (Keystone): Fix Released Bug description: Enabling the Federation extension, according with doc/source/extensions/federation-configuration.rst makes Keystone crash with the following exception: Traceback (most recent call last): File /usr/lib/cgi-bin/keystone/main, line 60, in module dependency.resolve_future_dependencies() File /opt/stack/keystone/keystone/common/dependency.py, line 251, in resolve_future_dependencies raise UnresolvableDependencyException(dependency) UnresolvableDependencyException: Unregistered dependency: federation_api Since the dependency is never registered. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1275695/+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 1325608] [NEW] base L3's create_router should process extensions
Public bug reported: Change: https://github.com/openstack/neutron/commit/634fd1d23fb241bc4990275d5a4da0c3ab66e2de Tweaked base create_router in l3_db.py to process the extensions or not; however it was chosen at the time, to set the process_extensions flag to False. This effectively disable the ability for extensions made to create_router's method to handle extension's attributes correctly. A more appropriate value should be True, to once again, allow extensibility. ** Affects: neutron Importance: Undecided Assignee: Armando Migliaccio (armando-migliaccio) Status: New ** Tags: l3-ipam-dhcp ** Tags added: l3-ipam-dhcp ** Changed in: neutron Assignee: (unassigned) = Armando Migliaccio (armando-migliaccio) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1325608 Title: base L3's create_router should process extensions Status in OpenStack Neutron (virtual network service): New Bug description: Change: https://github.com/openstack/neutron/commit/634fd1d23fb241bc4990275d5a4da0c3ab66e2de Tweaked base create_router in l3_db.py to process the extensions or not; however it was chosen at the time, to set the process_extensions flag to False. This effectively disable the ability for extensions made to create_router's method to handle extension's attributes correctly. A more appropriate value should be True, to once again, allow extensibility. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1325608/+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 1325654] [NEW] Race: Info cache for instance could not be found during boot
Public bug reported: Related to https://bugs.launchpad.net/nova/+bug/1324793 If an instance is deleted during the boot process then the instance.refresh() call in the conductor build_instances method should raise an InstanceNotFound exception. But as seen in the bug linked above it can sometimes raise an InstanceInfoCacheNotFound. This is odd because it seems to mean that the instance was deleted but if that was the case then InstanceNotFound should have been raised before the info cache lookup began. This behavior could use some further investigation. ** Affects: nova Importance: Undecided Status: New -- 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/1325654 Title: Race: Info cache for instance could not be found during boot Status in OpenStack Compute (Nova): New Bug description: Related to https://bugs.launchpad.net/nova/+bug/1324793 If an instance is deleted during the boot process then the instance.refresh() call in the conductor build_instances method should raise an InstanceNotFound exception. But as seen in the bug linked above it can sometimes raise an InstanceInfoCacheNotFound. This is odd because it seems to mean that the instance was deleted but if that was the case then InstanceNotFound should have been raised before the info cache lookup began. This behavior could use some further investigation. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1325654/+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 1279509] Re: Docker Instance in multi_host network mode receives the wrong gateway ip address
trunk nova doesn't have the docker driver.
** Changed in: nova
Status: New = Invalid
--
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/1279509
Title:
Docker Instance in multi_host network mode receives the wrong gateway
ip address
Status in OpenStack Compute (Nova):
Invalid
Bug description:
A openstack docker setup in multi_host (FlatDHCPManager) network mode
assigns the wrong gateway address to docker container instances.
Currently does the docker driver use the gateway information delivered by
nova.
The gateway is always 10.0.0.1 (my private network). The IP address 10.0.0.1
is ot availbale.
I looked up the dnsmasq instances on all compute nodes which is in my case
node1: 10.0.0.3
node2: 10.0.0.5
I figured out if I set the default gateway of a docker container
instance to the IP address of the dnsmasq everything works as
expected. Therefor I assume that this has to be the gateway.
The correct dnsmasq IP address is delivered in the the network_info as
shown in the example below (meta': {u'dhcp_server': u'10.0.0.5'}):
network_info:
{
'bridge': u'br100',
'subnets': [Subnet({
'ips': [FixedIP({
'meta': {},
'version': 4,
'type': u'fixed',
'floating_ips': [],
'address': u'10.0.0.10',
})],
'version': 4,
'meta': {u'dhcp_server': u'10.0.0.5'},
'dns': [IP({
'meta': {},
'version': 4,
'type': u'dns',
'address': u'10.129.184.2',
})],
'routes': [],
'cidr': u'10.0.0.0/24',
'gateway': IP({
'meta': {},
'version': 4,
'type': u'gateway',
'address': u'10.0.0.1',
}),
}),
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1279509/+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 1325666] [NEW] Create Flavor dialog - No visual difference between disabled filter field box and enabled filter field box in Flavor Access tab
Public bug reported: During the Flavor Creation process, once you get to the Flavor Acess tab, you're shown two panels, All Projects and Selected Projects. The All Projects filter field box is enabled, and you can type in it. The Selected Projects filter field box is disabled, I'm assuming because there are no projects selected by default, but the only way you know this is when you hover over it, and the cursor changes to a disabled/cancel cursor. It would be nice if there was a visual distinction between the two states, so you could know at a glance that one was disabled and the other wasn't. They have sort of a gray, disabled look to them even when enabled. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: Flavor Access tab without hovering https://bugs.launchpad.net/bugs/1325666/+attachment/4124264/+files/Flavor_Access.png -- 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/1325666 Title: Create Flavor dialog - No visual difference between disabled filter field box and enabled filter field box in Flavor Access tab Status in OpenStack Dashboard (Horizon): New Bug description: During the Flavor Creation process, once you get to the Flavor Acess tab, you're shown two panels, All Projects and Selected Projects. The All Projects filter field box is enabled, and you can type in it. The Selected Projects filter field box is disabled, I'm assuming because there are no projects selected by default, but the only way you know this is when you hover over it, and the cursor changes to a disabled/cancel cursor. It would be nice if there was a visual distinction between the two states, so you could know at a glance that one was disabled and the other wasn't. They have sort of a gray, disabled look to them even when enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325666/+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 1325664] [NEW] ML2: validate network configuration
Public bug reported: Validate that each physical_network name is neither empty nor too long. When a network is added we should make sure the physical_network name is appropriately configured (see comments in code plugins/ml2/drivers/type_flat.py as well type_vlan.py) ** Affects: neutron Importance: Undecided Assignee: Manish Godara (manishatyhoo) Status: New ** Changed in: neutron Assignee: (unassigned) = Manish Godara (manishatyhoo) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1325664 Title: ML2: validate network configuration Status in OpenStack Neutron (virtual network service): New Bug description: Validate that each physical_network name is neither empty nor too long. When a network is added we should make sure the physical_network name is appropriately configured (see comments in code plugins/ml2/drivers/type_flat.py as well type_vlan.py) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1325664/+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 1325668] [NEW] invalid operations in federation docs to install mod_shib
Public bug reported: In the keystone federation docs (http://docs.openstack.org/developer/keystone/configure_federation.html), the following paragraph is seen: You’ll also need to install Shibboleth, for example: $ apt-get libapache2-mod-shib2 However the keyword 'install' is missing. ** Affects: keystone Importance: Undecided Assignee: Steve Martinelli (stevemar) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1325668 Title: invalid operations in federation docs to install mod_shib Status in OpenStack Identity (Keystone): In Progress Bug description: In the keystone federation docs (http://docs.openstack.org/developer/keystone/configure_federation.html), the following paragraph is seen: You’ll also need to install Shibboleth, for example: $ apt-get libapache2-mod-shib2 However the keyword 'install' is missing. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1325668/+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 1325680] [NEW] Launch Instance dialog - UUIDs for NICs on the Networking tab are very difficult to read
Public bug reported: When you go to Launch an Instance, once you get to the Networking tab, it appears there's some sort of UUID displayed for each NIC, however, the font used for it is really tiny, and is very difficult to read. Would it be possible to use a tool tip/hover-over, or some sort of selection mechanism where you could show some details on the right side of the pane for a selected NIC? It seems like currently it's included just in case someone might need it, but even if they did need it, I'm not sure they'd be able to read it. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: Tiny text embedded in the NIC row https://bugs.launchpad.net/bugs/1325680/+attachment/4124293/+files/Launch_Instance_Networking_tab.png -- 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/1325680 Title: Launch Instance dialog - UUIDs for NICs on the Networking tab are very difficult to read Status in OpenStack Dashboard (Horizon): New Bug description: When you go to Launch an Instance, once you get to the Networking tab, it appears there's some sort of UUID displayed for each NIC, however, the font used for it is really tiny, and is very difficult to read. Would it be possible to use a tool tip/hover-over, or some sort of selection mechanism where you could show some details on the right side of the pane for a selected NIC? It seems like currently it's included just in case someone might need it, but even if they did need it, I'm not sure they'd be able to read it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325680/+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 1325685] [NEW] System Info - Services tab, rename 'Enabled' column entries
Public bug reported: There is a column in the Services table titled 'Enabled' with cell entries called 'Enabled' too. I think the cells should say [Yes/No] not [Enabled/Disabled]. If we want to keep the cell values as [Enabled/Disabled], the column heading should change (Status?). Please see attached image. ** 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/1325685 Title: System Info - Services tab, rename 'Enabled' column entries Status in OpenStack Dashboard (Horizon): New Bug description: There is a column in the Services table titled 'Enabled' with cell entries called 'Enabled' too. I think the cells should say [Yes/No] not [Enabled/Disabled]. If we want to keep the cell values as [Enabled/Disabled], the column heading should change (Status?). Please see attached image. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325685/+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] [NEW] Launch Instance dialog - nic should probably be capitalized on the Networking tab
Public bug reported: 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. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: nic is all lowercase https://bugs.launchpad.net/bugs/1325684/+attachment/4124294/+files/Launch_Instance_Networking_tab.png -- 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): New 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 1325688] [NEW] Some Languages start with capital letter but not all.
Public bug reported: Not All Languages in settings start with Capital Letters ** Affects: horizon Importance: Undecided Status: New ** Attachment added: capital_letters_in_languajes.PNG https://bugs.launchpad.net/bugs/1325688/+attachment/4124296/+files/capital_letters_in_languajes.PNG -- 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/1325688 Title: Some Languages start with capital letter but not all. Status in OpenStack Dashboard (Horizon): New Bug description: Not All Languages in settings start with Capital Letters To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325688/+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 1325692] [NEW] Extend Volume Dialog could be smarter
Public bug reported: I just made a 3gb test volume, and went to extend it. When the dialog opens, the Size field isn't filled out yet. It would be really nice if Size was pre-filled when the dialog was loaded with the current size, and then they can modify that up to extend it. I wondered if despite the name, you could use it to shrink a volume, and was greeted with an error after the dialog reloaded. It seems like it should be fairly easy to do some field level validation and not require a reload on this dialog when they try to extend a volume to a number we don't like. Additionally, if we're only letting them change the size of the volume, perhaps Name should be a read-only field and not marked required, rather than looking editable but having a disabled mouse cursor when you hover over it. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: What the user sees after opening the Extend Volume dialog https://bugs.launchpad.net/bugs/1325692/+attachment/4124297/+files/Extend_Volume_Just_Opened.png -- 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/1325692 Title: Extend Volume Dialog could be smarter Status in OpenStack Dashboard (Horizon): New Bug description: I just made a 3gb test volume, and went to extend it. When the dialog opens, the Size field isn't filled out yet. It would be really nice if Size was pre-filled when the dialog was loaded with the current size, and then they can modify that up to extend it. I wondered if despite the name, you could use it to shrink a volume, and was greeted with an error after the dialog reloaded. It seems like it should be fairly easy to do some field level validation and not require a reload on this dialog when they try to extend a volume to a number we don't like. Additionally, if we're only letting them change the size of the volume, perhaps Name should be a read-only field and not marked required, rather than looking editable but having a disabled mouse cursor when you hover over it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325692/+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 1320855] Re: sql: migration from 37 to 38 version fails
** Also affects: keystone/icehouse
Importance: Undecided
Status: New
** Changed in: keystone/icehouse
Importance: Undecided = Medium
** Changed in: keystone/icehouse
Assignee: (unassigned) = Emilien Macchi (emilienm)
** Changed in: keystone/icehouse
Status: New = In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1320855
Title:
sql: migration from 37 to 38 version fails
Status in OpenStack Identity (Keystone):
Fix Committed
Status in Keystone icehouse series:
In Progress
Bug description:
Migration from Havana to Icehouse fails due to db_sync error, when
migrating 37 to 38 sql schema:
CRITICAL keystone [-] OperationalError: (OperationalError) (1005,
Can't create table 'keystone.assignment' (errno: 150)) \nCREATE
TABLE assignment (\n\ttype
ENUM('UserProject','GroupProject','UserDomain','GroupDomain') NOT
NULL, \n\tactor_id VARCHAR(64) NOT NULL, \n\ttarget_id VARCHAR(64) NOT
NULL, \n\trole_id VARCHAR(64) NOT NULL, \n\tinherited BOOL NOT NULL,
\n\tPRIMARY KEY (type, actor_id, target_id, role_id), \n\tFOREIGN
KEY(role_id) REFERENCES role (id), \n\tCHECK (inherited IN (0,
1))\n)\n\n ()#0122014-05-19 09:57:51.445 40373 TRACE keystone
Traceback (most recent call last):#0122014-05-19 09:57:51.445 40373
TRACE keystone File /usr/bin/keystone-manage, line 51, in
module#0122014-05-19 09:57:51.445 40373 TRACE keystone
cli.main(argv=sys.argv, config_files=config_files)#0122014-05-19
09:57:51.445 40373 TRACE keystone File /usr/lib/python2.7/dist-
packages/keystone/cli.py, line 191, in main#0122014-05-19
09:57:51.445 40373 TRACE keystone
CONF.command.cmd_class.main()#0122014-05-19 09:57:51.445 40373 TRACE
keystone File /usr/lib/python2.7/dist-packages/keystone/cli.py,
line 67, in main#0122014-05-19 09:57:51.445 40373 TRACE keystone
migration_helpers.sync_database_to_version(extension,
version)#0122014-05-19 09:57:51.445 40373 TRACE keystone File
/usr/lib/python2.7/dist-
packages/keystone/common/sql/migration_helpers.py, line 139, in
sync_database_to_version#0122014-05-19 09:57:51.445 40373 TRACE
keystone migration.db_sync(sql.get_engine(), abs_path,
version=version)#0122014-05-19 09:57:51.445 40373 TRACE keystone
File /usr/lib/python2.7/dist-
packages/keystone/openstack/common/db/sqlalchemy/migration.py, line
197, in db_sync#0122014-05-19 09:57:51.445 40373 TRACE keystone
return versioning_api.upgrade(engine, repository,
version)#0122014-05-19 09:57:51.445 40373 TRACE keystone File
/usr/lib/python2.7/dist-packages/migrate/versioning/api.py, line
186, in upgrade#0122014-05-19 09:57:51.445 40373 TRACE keystone
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1320855/+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 1325701] [NEW] Create Volume dialog - No helper text for Type, and no guidance on how to create one
Public bug reported: When you create a Volume, and you don't have a Type defined, there's nothing in the dropdown. While it's empty, and not marked as required, it still makes me a little nervous and wonder what I'm missing out on by not having a Type to pick. Many other dropdowns in OpenStack either have a default value, or some helper text instead of just being empty. The Launch Instance dialog has --- Select source --- for Instance Boot Source, and on the Access Security tab, if you don't have any Key Pairs, it says No key pairs available, with a + button you can click that takes you to the Import Key Pair dialog. I'm honestly not sure how important Type is, especially since you can't seem to do much with it in the UI yet, and have to use the CLI to actually configure more than a Name for it, but it seems like there should be some helper text or a string that says they don't have one yet, and possibly help link them over to where they could create one. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: Empty Type Dropdown https://bugs.launchpad.net/bugs/1325701/+attachment/4124307/+files/Create_Volume_Type_Dropdown.png -- 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/1325701 Title: Create Volume dialog - No helper text for Type, and no guidance on how to create one Status in OpenStack Dashboard (Horizon): New Bug description: When you create a Volume, and you don't have a Type defined, there's nothing in the dropdown. While it's empty, and not marked as required, it still makes me a little nervous and wonder what I'm missing out on by not having a Type to pick. Many other dropdowns in OpenStack either have a default value, or some helper text instead of just being empty. The Launch Instance dialog has --- Select source --- for Instance Boot Source, and on the Access Security tab, if you don't have any Key Pairs, it says No key pairs available, with a + button you can click that takes you to the Import Key Pair dialog. I'm honestly not sure how important Type is, especially since you can't seem to do much with it in the UI yet, and have to use the CLI to actually configure more than a Name for it, but it seems like there should be some helper text or a string that says they don't have one yet, and possibly help link them over to where they could create one. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325701/+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 1325705] [NEW] Cells - prominent hypervisor version filter bug
Public bug reported: Commit 0c22f71fb338b1aa7c4a2b30555449a464ad3874 introduced a filter that allowed the cells scheduler to route instance builds to cells with a matching 'prominent' hypervisor version. (nova.cells.filters.image_properties.ImagePropertiesFilter). This filter has a bug where the set of cell capabilities is mutated via set pop(). This causes a race where the filter can fail if it runs again before the capabilities list gets repopulated from the child cell. ** Affects: nova Importance: Undecided Status: New -- 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/1325705 Title: Cells - prominent hypervisor version filter bug Status in OpenStack Compute (Nova): New Bug description: Commit 0c22f71fb338b1aa7c4a2b30555449a464ad3874 introduced a filter that allowed the cells scheduler to route instance builds to cells with a matching 'prominent' hypervisor version. (nova.cells.filters.image_properties.ImagePropertiesFilter). This filter has a bug where the set of cell capabilities is mutated via set pop(). This causes a race where the filter can fail if it runs again before the capabilities list gets repopulated from the child cell. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1325705/+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 1325725] [NEW] tempest doesn't have integration testing on nova's quota-class API
Public bug reported: Related: https://bugs.launchpad.net/horizon/+bug/1292589 Nova shouldn't have been able to remove that functionality if horizon was using it. So we have a gap in testing the APIs that horizon is using. ** 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/1325725 Title: tempest doesn't have integration testing on nova's quota-class API Status in OpenStack Dashboard (Horizon): New Bug description: Related: https://bugs.launchpad.net/horizon/+bug/1292589 Nova shouldn't have been able to remove that functionality if horizon was using it. So we have a gap in testing the APIs that horizon is using. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325725/+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 1325726] [NEW] It isn't clear from the UI that Volume Types can only really be configured from the CLI
Public bug reported: From the Create Volume Type dialog, I'm told The volume type defines the characteristics of a volume. It usually maps to a set of capabilities of the storage back-end driver to be used for this volume. Examples: Performance, SSD, Backup, etc. Yet all I can actually do within the dialog is give it a name. If this functionality is only accessible through the CLI, it would be nice to mention that in the UI, and not hope they find that out through the Docs. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: screenshot of the dialog https://bugs.launchpad.net/bugs/1325726/+attachment/4124373/+files/Create_Volume_Type.png -- 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/1325726 Title: It isn't clear from the UI that Volume Types can only really be configured from the CLI Status in OpenStack Dashboard (Horizon): New Bug description: From the Create Volume Type dialog, I'm told The volume type defines the characteristics of a volume. It usually maps to a set of capabilities of the storage back-end driver to be used for this volume. Examples: Performance, SSD, Backup, etc. Yet all I can actually do within the dialog is give it a name. If this functionality is only accessible through the CLI, it would be nice to mention that in the UI, and not hope they find that out through the Docs. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325726/+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 1325731] [NEW] libvirt out of sync with nova causes instance to endlessly reschedule
Public bug reported: 2014-06-02 13:32:26.404 ERROR nova.compute.manager [req-7aaaef0e-46ed-4547-acec-d788aa3aafc8 demo demo] [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] Instance failed to spawn 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] Traceback (most recent call last): 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/compute/manager.py, line 2062, in _build_resources 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] yield resources 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/compute/manager.py, line 1965, in _build_and_run_instance 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] block_device_info=block_device_info) 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 2288, in spawn 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] block_device_info) 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 3684, in _create_domain_and_network 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] power_on=power_on) 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 3582, in _create_domain 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] raise e 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] libvirtError: operation failed: domain 'instance-0002' already exists with uuid f24839a2-6523-438b-a4c3-b46ddba11389 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] 2014-06-02 13:32:26.406 ERROR root [req-7aaaef0e-46ed-4547-acec-d788aa3aafc8 demo demo] Original exception being dropped: ['Traceback (most recent call last):\n', ' File /opt/stack/nova/nova/compute/manager.py, line 2062, in _build_resources\nyield resources\n', ' File /opt/stack/nova/nova/compute/manager.py, line 1965, in _build_and_run_instance\nblock_device_info=block_device_info)\n', ' File /opt/stack/nova/nova/virt/libvirt/driver.py, line 2288, in spawn\n block_device_info)\n', ' File /opt/stack/nova/nova/virt/libvirt/driver.py, line 3684, in _create_domain_and_network\npower_on=power_on)\n', ' File /opt/stack/nova/nova/virt/libvirt/driver.py, line 3582, in _create_domain\n raise e\n', libvirtError: operation failed: domain 'instance-0002' already exists with uuid f24839a2-6523-438b-a4c3-b46ddba11389\n] ** Affects: nova Importance: Undecided Status: New -- 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/1325731 Title: libvirt out of sync with nova causes instance to endlessly reschedule Status in OpenStack Compute (Nova): New Bug description: 2014-06-02 13:32:26.404 ERROR nova.compute.manager [req-7aaaef0e-46ed-4547-acec-d788aa3aafc8 demo demo] [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] Instance failed to spawn 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] Traceback (most recent call last): 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/compute/manager.py, line 2062, in _build_resources 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] yield resources 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/compute/manager.py, line 1965, in _build_and_run_instance 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] block_device_info=block_device_info) 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 2288, in spawn 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] block_device_info) 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance: 0bb3d301-96c7-44f4-8235-ba0d062a011b] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 3684, in _create_domain_and_network 2014-06-02 13:32:26.404 TRACE nova.compute.manager [instance:
[Yahoo-eng-team] [Bug 1325684] Re: Launch Instance dialog - nic should probably be capitalized on the Networking tab
To fix this bug completely, it is needed to update the localization files, I am creating a new entry for i18n team. The localization changes have to be done over the horizon modifications to be submitted soon. ** Also affects: openstack-i18n 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/1325684 Title: Launch Instance dialog - nic should probably be capitalized on the Networking tab Status in OpenStack Dashboard (Horizon): New Status in OpenStack I18n L10n: New 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 1325736] [NEW] Security Group Rules can only be specified in one direction
Public bug reported: It might save users potentially a lot of time if instead of only offering an INGRESS and an EGRESS direction, if they could specify a BOTH direction. Whenever someone needs to enter both an ingress and egress rule for the same port they have to enter it twice, remembering all of the information they need (since it can't be cloned). If they forget to flip the direction the second time from the default value, it'll error out as a duplicate and they'll have to try a third time. If they messed up the second rule, there's no edit, so they would have to delete it if they got a value wrong and do it all over again. It would be awesome if the UI allowed for specifying both an ingress and egress rule at the same time, even if all it did was create the ingress and egress rows and put them in the table, at least they'd be guaranteed to have the same configuration. ** Affects: horizon Importance: Undecided Status: New ** Tags: low-hanging-fruit ux ** Attachment added: Can't create a rule that opens up a port in both directions at once https://bugs.launchpad.net/bugs/1325736/+attachment/4124384/+files/Security_Rule_Creation_Direction.png -- 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/1325736 Title: Security Group Rules can only be specified in one direction Status in OpenStack Dashboard (Horizon): New Bug description: It might save users potentially a lot of time if instead of only offering an INGRESS and an EGRESS direction, if they could specify a BOTH direction. Whenever someone needs to enter both an ingress and egress rule for the same port they have to enter it twice, remembering all of the information they need (since it can't be cloned). If they forget to flip the direction the second time from the default value, it'll error out as a duplicate and they'll have to try a third time. If they messed up the second rule, there's no edit, so they would have to delete it if they got a value wrong and do it all over again. It would be awesome if the UI allowed for specifying both an ingress and egress rule at the same time, even if all it did was create the ingress and egress rows and put them in the table, at least they'd be guaranteed to have the same configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325736/+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 1246941] Re: Trust Auth is broken when Content Type is XML
** Changed in: keystone
Status: Invalid = In Progress
** Changed in: keystone
Assignee: Adam Young (ayoung) = Steve Martinelli (stevemar)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1246941
Title:
Trust Auth is broken when Content Type is XML
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
--- a/keystone/tests/test_v3_auth.py
+++ b/keystone/tests/test_v3_auth.py
@@ -2238,3 +2238,7 @@ class TestTrustAuth(TestAuthInfo):
self.get('/OS-TRUST/trusts?trustor_user_id=%s' %
self.user_id, expected_status=401,
token=trust_token)
+
+
+class TestTrustAuthXML(TestTrustAuth):
+content_type = 'xml'
And, when running it, I got:
Ran 24 tests in 5.832s
FAILED (SKIP=1, errors=12)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1246941/+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 1314125] Re: No errors when creating keystone tables when MySQL fails
** Also affects: openstack-manuals
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1314125
Title:
No errors when creating keystone tables when MySQL fails
Status in OpenStack Identity (Keystone):
New
Status in OpenStack Manuals:
New
Bug description:
By following documentation:
http://docs.openstack.org/icehouse/install-guide/install/yum/content
/keystone-install.html
When MySQL controller is not changed in /etc/keystone/keystone.conf
Then when you are using su -s /bin/sh -c keystone-manage db_sync
keystone command won't produce any errors.. errors appear only when
you add an user for example:
keystone user-create --name=admin --pass=password --email=em...@email.com
An unexpected error prevented the server from fulfilling your request. (HTTP
500)
In keystone.log file there will be:
CRITICAL keystone [-] OperationalError: (OperationalError) (2005, Unknown
MySQL server host 'controller' (1)) None None
If controller is changed in /etc/keystone/keystone.conf user must re-run
following command:
su -s /bin/sh -c keystone-manage db_sync keystone
otherwise when they try to create an user they will receive the error
above and error in keystone.log
TRACE keystone.common.wsgi ProgrammingError: (ProgrammingError) (1146,
Table 'keystone.domain' doesn't exist) 'SELECT domain.id AS
domain_id, domain.name AS domain_name, domain.enabled AS
domain_enabled, domain.extra AS domain_extra \nFROM domain \nWHERE
domain.id = %s' ('default',)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1314125/+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 1325787] [NEW] Create Image, fields are not persisted
Public bug reported: == How to Reproduce: == 1. Admin Images 2. Click on 'Create Image' 3. Enter name, *description*, image location, format and *architecture* For image location, put in a link, I went here: https://github.com/rackerjoe/oz-image-build and used the first one in the list: RedHat 5 Update 6 (http://c250663.r63.cf1.rackcdn.com/rhel56_x86_64.qcow2) 4. Press Create Image 5. Once the upload is complete, click on the image name to view details. 6. You will notice that *description* and *architecture* is missing from the UI 7. Go back to table. press on 'Edit' for that entry. Likewise, You will see that *description* and *architecture* are empty. Here, if you you can put something into *description* and press save, it will work and show up in the detail view. However, *architecture* is readonly and unable to update. ** 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/1325787 Title: Create Image, fields are not persisted Status in OpenStack Dashboard (Horizon): New Bug description: == How to Reproduce: == 1. Admin Images 2. Click on 'Create Image' 3. Enter name, *description*, image location, format and *architecture* For image location, put in a link, I went here: https://github.com/rackerjoe/oz-image-build and used the first one in the list: RedHat 5 Update 6 (http://c250663.r63.cf1.rackcdn.com/rhel56_x86_64.qcow2) 4. Press Create Image 5. Once the upload is complete, click on the image name to view details. 6. You will notice that *description* and *architecture* is missing from the UI 7. Go back to table. press on 'Edit' for that entry. Likewise, You will see that *description* and *architecture* are empty. Here, if you you can put something into *description* and press save, it will work and show up in the detail view. However, *architecture* is readonly and unable to update. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325787/+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 1325789] [NEW] VMware: vm_util.get_host_ref() should take into account where the VM is located
Public bug reported: vm_util.get_host_ref() returns the first host in the list of hosts returned by vCenter. This behavior is not correct when we want to get the host where the VM is running. We need to provide the VM reference and return the host where the VM is running. See: http://www.mail-archive.com/openstack- d...@lists.openstack.org/msg25648.html for more details ** Affects: nova Importance: Undecided Assignee: Arnaud Legendre (arnaudleg) Status: New ** Changed in: nova Assignee: (unassigned) = Arnaud Legendre (arnaudleg) -- 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/1325789 Title: VMware: vm_util.get_host_ref() should take into account where the VM is located Status in OpenStack Compute (Nova): New Bug description: vm_util.get_host_ref() returns the first host in the list of hosts returned by vCenter. This behavior is not correct when we want to get the host where the VM is running. We need to provide the VM reference and return the host where the VM is running. See: http://www.mail-archive.com/openstack- d...@lists.openstack.org/msg25648.html for more details To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1325789/+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 1325800] [NEW] Potential Race Condition between L3NATAgent.routers_updated and L3NATAgent._rpc_loop.
Public bug reported: The _rpc_loop routine takes a snapshot of the L3NATAgent’s routers_updated set and then it clears the set. At the same time, L3NATAgent.routers_updated can run, it adds new routers to the routers_updated set. It is possible for both routines to run at the same time. So it is possible that _rpc_loop will clear the routers_updated set right after routers_updated routine added a router without having the new router included in the snapshot. The problem will manifests itself by having a newly associated floating ip address not being configured in the iptables and the qg- device. ** Affects: neutron Importance: Undecided Assignee: Stephen Ma (stephen-ma) Status: New ** Changed in: neutron Assignee: (unassigned) = Stephen Ma (stephen-ma) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1325800 Title: Potential Race Condition between L3NATAgent.routers_updated and L3NATAgent._rpc_loop. Status in OpenStack Neutron (virtual network service): New Bug description: The _rpc_loop routine takes a snapshot of the L3NATAgent’s routers_updated set and then it clears the set. At the same time, L3NATAgent.routers_updated can run, it adds new routers to the routers_updated set. It is possible for both routines to run at the same time. So it is possible that _rpc_loop will clear the routers_updated set right after routers_updated routine added a router without having the new router included in the snapshot. The problem will manifests itself by having a newly associated floating ip address not being configured in the iptables and the qg- device. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1325800/+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 1318770] Re: nova usage list to show tenant name.
This is a novaclient feature, not a nova one ** Also affects: python-novaclient Importance: Undecided Status: New ** Changed in: nova Status: New = Invalid ** Changed in: python-novaclient Importance: Undecided = Wishlist -- 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/1318770 Title: nova usage list to show tenant name. Status in OpenStack Compute (Nova): Invalid Status in Python client library for Nova: New Bug description: $nova --version 2.17.0.75 When I issue nova usage list command , I get the following details. $ nova usage-list Usage from 2014-04-11 to 2014-05-10: +--+-+--+---+---+ | Tenant ID| Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours | +--+-+--+---+---+ | 41a0db24bc8940b6a2f3297bef5f6cee | 3 | 1478.70 | 23.10 | 0.00 | | 0dceee00627f44838174cccb6bf29421 | 3 | 172.36 | 1.36 | 0.00 | +--+-+--+---+---+ From the Tenant ID, I cannot able to know what tenant name it is . I want to know the tenant name. Because tenant ID is long to remember. To get tenant name , we have to use keystone tenant list. My proposal is to include tenant name in the current columns of nova usage list. So that user can easily recognize its tenant name. As the same thing is available in Horizon Dashboard. Is their any problems or dependices so that we are not including tenant name. If yes, please share the details for it. I would like to do the code executions for this. Thank you RITESH. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1318770/+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 1325812] [NEW] HACKING rst does not have rules N320
Public bug reported: Commit 9235ada8c2c250603dc5b299cc08bb7a982d4fc6 did not add the rule to the HACKING.rst ** Affects: nova Importance: Medium Assignee: Gary Kotton (garyk) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Changed in: nova Importance: Undecided = Medium ** Changed in: nova Milestone: None = juno-1 -- 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/1325812 Title: HACKING rst does not have rules N320 Status in OpenStack Compute (Nova): In Progress Bug description: Commit 9235ada8c2c250603dc5b299cc08bb7a982d4fc6 did not add the rule to the HACKING.rst To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1325812/+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
