[Yahoo-eng-team] [Bug 1611940] Re: vncserver_proxyclient_address changed from stropt to ipopt, breaking backwards compat without deprecation
Reviewed: https://review.openstack.org/353710 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9289e6212cf54a4ce74c7615cf74892c6a70c50d Submitter: Jenkins Branch:master commit 9289e6212cf54a4ce74c7615cf74892c6a70c50d Author: Sean Dague Date: Wed Aug 10 16:00:53 2016 -0400 vnc host options need to support hostnames When updating the config options the VNC options were switched from StrOpt to IPOpt. However these are hostnames, they even say so in the option name, so IPOpt is too restrictive, and could break folks in upgrade if they set these to hostnames. Change-Id: Ib2062407dcf9cba8676b0f38aa0c63df25cc7b38 Closes-Bug: #1611940 ** Changed in: nova Status: New => 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/1611940 Title: vncserver_proxyclient_address changed from stropt to ipopt, breaking backwards compat without deprecation Status in OpenStack Compute (nova): Fix Released Bug description: The change https://review.openstack.org/#/c/348442/ introduced a backwards incompatible change, specifically at: https://review.openstack.org/#/c/348442/3/nova/conf/vnc.py@68 where vncserver_proxyclient_address was changed from a StrOpt to an IpOpt. This broke backwards compatibility without a proper deprecation notice being introduced and there are especially no release notes that mention this. When running with this new commit, users that configured that parameter as a hostname are now greeted with a stack trace from nova-compute: 2016-08-10 19:26:35.458 10624 CRITICAL nova [req-c235cb33-49c4-4f97-a4a1-0523f134afdc - - - - -] ConfigFileValueError: Value for option vncserver_proxyclient_address is not valid: n59.ci.centos.org is not IPv4 or IPv6 address 2016-08-10 19:26:35.458 10624 ERROR nova Traceback (most recent call last): 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/bin/nova-compute", line 10, in 2016-08-10 19:26:35.458 10624 ERROR nova sys.exit(main()) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/nova/cmd/compute.py", line 78, in main 2016-08-10 19:26:35.458 10624 ERROR nova service.wait() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait 2016-08-10 19:26:35.458 10624 ERROR nova _launcher.wait() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait 2016-08-10 19:26:35.458 10624 ERROR nova status, signo = self._wait_for_exit_or_signal() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 303, in _wait_for_exit_or_signal 2016-08-10 19:26:35.458 10624 ERROR nova self.conf.log_opt_values(LOG, logging.DEBUG) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2591, in log_opt_values 2016-08-10 19:26:35.458 10624 ERROR nova _sanitize(opt, getattr(group_attr, opt_name))) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3022, in __getattr__ 2016-08-10 19:26:35.458 10624 ERROR nova return self._conf._get(name, self._group) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2633, in _get 2016-08-10 19:26:35.458 10624 ERROR nova value = self._do_get(name, group, namespace) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2676, in _do_get 2016-08-10 19:26:35.458 10624 ERROR nova % (opt.name, str(ve))) 2016-08-10 19:26:35.458 10624 ERROR nova ConfigFileValueError: Value for option vncserver_proxyclient_address is not valid: n59.ci.centos.org is not IPv4 or IPv6 address 2016-08-10 19:26:35.458 10624 ERROR nova To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611940/+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 1501238] Re: Unable to create a project at first time
As I know, project data is stored in KEYSTONE. There is no database in Horizon. Your bug should be in KEYSTONE maybe ? ** Changed in: horizon Status: New => Opinion -- 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/1501238 Title: Unable to create a project at first time Status in OpenStack Dashboard (Horizon): Opinion Bug description: After installing all the components of openstack, I entered into the portal with admin credentials. Initially I required to create a project for a tenant, So I tried to create a project it throws an error "Danger Unable to create a project". Then I created a new user, after that I created a project, it is created. It is expecting that at-least one normal user should be found. Due to this I want to experiment more, I deleted all the normal user and projects then I created a project, now It is created. working fine. Bug: Initially it expects at-least one user should be created before the project. But the workflow says that you should add at least one project before adding users. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1501238/+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 1612069] [NEW] HA router state change takes too much time to notify neutron server
Public bug reported: The ha state change BatchNotifier uses the following calculated interval. def _calculate_batch_duration(self): # Slave becomes the master after not hearing from it 3 times detection_time = self.conf.ha_vrrp_advert_int * 3 # Keepalived takes a couple of seconds to configure the VIPs configuration_time = 2 # Give it enough slack to batch all events due to the same failure return (detection_time + configuration_time) * 2 It takes almost 16s, by default ha_vrrp_advert_int is 2s, for a single HA router state change to notify neutron server. Actually before this notify, the ip MonitorDaemon has already set the router to its relevant state. So no need to wait this long time. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ha ** Summary changed: - HA router state change take too much time to notify neutron server + HA router state change takes too much time to notify neutron server ** Description changed: The ha state change BatchNotifier uses the following calculated interval. def _calculate_batch_duration(self): # Slave becomes the master after not hearing from it 3 times detection_time = self.conf.ha_vrrp_advert_int * 3 # Keepalived takes a couple of seconds to configure the VIPs configuration_time = 2 # Give it enough slack to batch all events due to the same failure return (detection_time + configuration_time) * 2 - It takes almost 16s for a single HA router state change to notify neutron server. + It takes almost 16s, by default ha_vrrp_advert_int is 2s, for a single HA router state change to notify neutron server. Actually before this notify, the ip MonitorDaemon has already set the router to its relevant state. So no need to wait this long time. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1612069 Title: HA router state change takes too much time to notify neutron server Status in neutron: New Bug description: The ha state change BatchNotifier uses the following calculated interval. def _calculate_batch_duration(self): # Slave becomes the master after not hearing from it 3 times detection_time = self.conf.ha_vrrp_advert_int * 3 # Keepalived takes a couple of seconds to configure the VIPs configuration_time = 2 # Give it enough slack to batch all events due to the same failure return (detection_time + configuration_time) * 2 It takes almost 16s, by default ha_vrrp_advert_int is 2s, for a single HA router state change to notify neutron server. Actually before this notify, the ip MonitorDaemon has already set the router to its relevant state. So no need to wait this long time. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1612069/+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 1609625] Re: The 'create:forced_host' policy is set to 'rule:admin_or_owner' by default
Reviewed: https://review.openstack.org/351077 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=16a38564cb61031466bf60ac393363bfeaedbd93 Submitter: Jenkins Branch:master commit 16a38564cb61031466bf60ac393363bfeaedbd93 Author: Takashi NATSUME Date: Thu Aug 4 17:56:58 2016 +0900 Fix server operations' policies to admin only Before the following policies were set to admin only operations by default. * detail:get_all_tenants * index:get_all_tenants * create:forced_host But currently they are not limited to admin users by default. They were changed unintentionally in I71b3d1233255125cb280a000b990329f5b03fdfd. So set them admin only again. And a unit test for policy is fixed. Change-Id: I1c0a4f1ff19d68152953dd6b265a7fb2e0f6271a Closes-Bug: #1609625 Closes-Bug: #1609691 Closes-Bug: #1611628 ** 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/1609625 Title: The 'create:forced_host' policy is set to 'rule:admin_or_owner' by default Status in OpenStack Compute (nova): Fix Released Bug description: The 'create:forced_host' policy is set to 'rule:admin_or_owner' by default currently (master: 5d040245e750aab06c620344828c2182703515b7). https://github.com/openstack/nova/blob/5d040245e750aab06c620344828c2182703515b7/nova/policies/servers.py#L32 But it was 'rule:admin_api' before. It was changed in the following patch. https://review.openstack.org/#/c/329122/ It should be restored to a previous value. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1609625/+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 1609691] Re: Non-admin users can lists VM instances of other projects (tenants) by default
Reviewed: https://review.openstack.org/351077 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=16a38564cb61031466bf60ac393363bfeaedbd93 Submitter: Jenkins Branch:master commit 16a38564cb61031466bf60ac393363bfeaedbd93 Author: Takashi NATSUME Date: Thu Aug 4 17:56:58 2016 +0900 Fix server operations' policies to admin only Before the following policies were set to admin only operations by default. * detail:get_all_tenants * index:get_all_tenants * create:forced_host But currently they are not limited to admin users by default. They were changed unintentionally in I71b3d1233255125cb280a000b990329f5b03fdfd. So set them admin only again. And a unit test for policy is fixed. Change-Id: I1c0a4f1ff19d68152953dd6b265a7fb2e0f6271a Closes-Bug: #1609625 Closes-Bug: #1609691 Closes-Bug: #1611628 ** 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/1609691 Title: Non-admin users can lists VM instances of other projects (tenants) by default Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Non-admin users can lists VM instances of other projects (tenants) by default. They should not be able to see VM instances of other projects by default. stack@devstack-master:/opt/devstack$ openstack project list +--++ | ID | Name | +--++ | 33621006e3744ecea0b7090658601929 | alt_demo | | 6773c471c311455d862ed22f685574b0 | admin | | 850f809b7ee5469f8aa639b4717f58a5 | demo | | 95a64b7c097e4b69bd8af9224f332cd6 | invisible_to_admin | | c65ecc9a29e64e83bedf0609bb27266f | service| +--++ stack@devstack-master:/opt/devstack$ openstack user list +--+--+ | ID | Name | +--+--+ | 60066d4ac41a44d1ab6abea61809e78a | admin| | 896d17cb7d0f49f585ce460f61f35a5a | demo | | 6fcc02a6cfa64de097d15d2535d0108e | alt_demo | | b703f8d08aae46e0bad0fe3022d13250 | nova | | 205a38f88db84c13bb84274456da8b69 | glance | | c2a64c7cffae430493dac9d8b4ef6470 | cinder | | 5ad6f4ce7c64489e965d56eba081e2a9 | neutron | | 2d16f7d5f324446dbfa30db2a04f9658 | heat | +--+--+ stack@devstack-master:/opt/devstack$ openstack user role list --project admin admin +--+---+-+---+ | ID | Name | Project | User | +--+---+-+---+ | 915b08cc7e6b40ceb55a803e8a843d0d | admin | admin | admin | +--+---+-+---+ stack@devstack-master:/opt/devstack$ openstack user role list --project demo demo +--+-+-+--+ | ID | Name| Project | User | +--+-+-+--+ | cf49079e087a4c61935bac9a5c6c224d | Member | demo| demo | | 664e30492b954257ae579e8498c4fc78 | anotherrole | demo| demo | +--+-+-+--+ Operated by admin: stack@devstack-master:/opt/devstack$ nova show server1 +--++ | Property | Value | +--++ (snipped...) | OS-EXT-STS:vm_state | active | (snipped...) | id | 853d681b-de17-4fd3-bcd6-0f91d153ccd6 | (snipped...) | name | server1 | (snipped...) | tenant_id| 6773c471c311455d862ed22f685574b0 | * admin | updated | 2016-08-04T08:09:49Z | | user_id | 60066d4ac41a44d1ab6abea61809e78a | * admin +--++ Operated by demo: stack@devstack-master:/opt/dev
[Yahoo-eng-team] [Bug 1611628] Re: test_admin_only_rules doesn't check an 'admin_or_owner' case correctly
Reviewed: https://review.openstack.org/351077 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=16a38564cb61031466bf60ac393363bfeaedbd93 Submitter: Jenkins Branch:master commit 16a38564cb61031466bf60ac393363bfeaedbd93 Author: Takashi NATSUME Date: Thu Aug 4 17:56:58 2016 +0900 Fix server operations' policies to admin only Before the following policies were set to admin only operations by default. * detail:get_all_tenants * index:get_all_tenants * create:forced_host But currently they are not limited to admin users by default. They were changed unintentionally in I71b3d1233255125cb280a000b990329f5b03fdfd. So set them admin only again. And a unit test for policy is fixed. Change-Id: I1c0a4f1ff19d68152953dd6b265a7fb2e0f6271a Closes-Bug: #1609625 Closes-Bug: #1609691 Closes-Bug: #1611628 ** 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/1611628 Title: test_admin_only_rules doesn't check an 'admin_or_owner' case correctly Status in OpenStack Compute (nova): Fix Released Bug description: The test_admin_only_rules method of RealRolePolicyTestCase class in nova/tests/unit/test_policy.py doesn't check an 'admin_or_owner' case correctly. def test_admin_only_rules(self): for rule in self.admin_only_rules: self.assertRaises(exception.PolicyNotAuthorized, policy.authorize, self.non_admin_context, rule, self.target) policy.authorize(self.admin_context, rule, self.target) https://github.com/openstack/nova/blob/3d6e72689ee18a779d70405d11e09a69183cc853/nova/tests/unit/test_policy.py#L495 If an admin only rule in source code is changed to 'admin_or_owner' rule by mistake, the assertRaises statement raises a PolicyNotAuthorized exception because it is not that the context is non admin user but the owner is defferent. So the target should be set to same project of non admin context. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611628/+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 1612056] [NEW] Neutron-Vpnaas Rally run fails with error 'module' object has no attribute 'set'
Public bug reported: Neutron-Vpnaas Rally run fails with error Failed to load module with plugins /opt/rally/plugins/test_vpn_status.py: 'module' object has no attribute 'set'. Actual: In the latest code of the types: First, we will add a new function, ``types.convert()``, to replace ``types.set()``. ``types.convert()`` will accept arguments differently Reference : https://github.com/openstack/rally/blob/14726077d41b4b883637b808236d780f0d9c3c7b/doc/release_notes/archive/v0.3.3.rst ** Affects: neutron Importance: Undecided Assignee: Ashish Kumar Gupta (ashish-kumar-gupta) Status: New ** Changed in: neutron Assignee: (unassigned) => Ashish Kumar Gupta (ashish-kumar-gupta) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1612056 Title: Neutron-Vpnaas Rally run fails with error 'module' object has no attribute 'set' Status in neutron: New Bug description: Neutron-Vpnaas Rally run fails with error Failed to load module with plugins /opt/rally/plugins/test_vpn_status.py: 'module' object has no attribute 'set'. Actual: In the latest code of the types: First, we will add a new function, ``types.convert()``, to replace ``types.set()``. ``types.convert()`` will accept arguments differently Reference : https://github.com/openstack/rally/blob/14726077d41b4b883637b808236d780f0d9c3c7b/doc/release_notes/archive/v0.3.3.rst To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1612056/+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 1612057] [NEW] XenAPI: Wrong calculation of available disk
Public bug reported: https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/xenapi/host.py#n230 will report the virtual utilisation of the SR; which is intentional as the assumption is that VMs may eventually use all of the space they are entitled to. However, this does not have to include glance images. For example: [root@maul ~]# xe vdi-list name-label="Glance Image 792e7f09-0c87-4f60-9861-b580fbc3c9cb" params=virtual-size,physical-utilisation virtual-size ( RO): 42949672960 physical-utilisation ( RO): 88576 Because the VHD has a virtual size of 40GB when uploaded to glance, the VDI has to be 40GB, but we know it can never increase because we will always take a snapshot of it. This, this 88K of physical utilisation is interpreted as 40GB by our code. ** Affects: nova Importance: Undecided Assignee: John Hua (john-hua) Status: New ** Changed in: nova Assignee: (unassigned) => John Hua (john-hua) -- 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/1612057 Title: XenAPI: Wrong calculation of available disk Status in OpenStack Compute (nova): New Bug description: https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/xenapi/host.py#n230 will report the virtual utilisation of the SR; which is intentional as the assumption is that VMs may eventually use all of the space they are entitled to. However, this does not have to include glance images. For example: [root@maul ~]# xe vdi-list name-label="Glance Image 792e7f09-0c87-4f60-9861-b580fbc3c9cb" params=virtual-size,physical-utilisation virtual-size ( RO): 42949672960 physical-utilisation ( RO): 88576 Because the VHD has a virtual size of 40GB when uploaded to glance, the VDI has to be 40GB, but we know it can never increase because we will always take a snapshot of it. This, this 88K of physical utilisation is interpreted as 40GB by our code. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1612057/+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 1612050] [NEW] Need more data added for RBAC policy notifications
Public bug reported:
For the Searchlight project, we are receiving notifications for the RBAC
policy commands.
rbac-create
rbac-delete
The payload for rbac_policy.create.end is complete and allows
Searchlight to update our state to reflect the policy changes.
The payload for rbac_policy.delete.end is not as complete. The payload
we receive is:
{
"event_type": "rbac_policy.delete.end",
"payload":
{ "rbac_policy_id": "d7491be9-ee3d-40d7-9880-0ce82c7c12f6" }
}
Since the RBAC policy is being deleted, we cannot query the details of
the policy through the Neutron API using the policy ID. Doing so results
in a race condition where the majority of the time the policy has
already been deleted.
This means we need to store the details of the policy upon
rbac_policy.create.end time, which requires extraneous state in
Searchlight.
We would like a change to the rbac_policy.delete.end payload to include
all policy's details. Mirroring the same information provided by the
rbac_policy.create.end notification:
{
"event_type": "rbac_policy.delete.end",
"payload":
{ "target_tenant": "admin", "tenant_id": "c4b424b17cc04cefa7211b40c5c893c2",
"object_type": "network", "object_id": "64f00d1c-a6b6-4c00-a800-10eb9360a976",
"action": "access_as_shared", "id": "d7491be9-ee3d-40d7-9880-0ce82c7c12f6" }
}
At a bare minimum, we would need "tenant_id", "object_id" and "id" to be
returned.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1612050
Title:
Need more data added for RBAC policy notifications
Status in neutron:
New
Bug description:
For the Searchlight project, we are receiving notifications for the
RBAC policy commands.
rbac-create
rbac-delete
The payload for rbac_policy.create.end is complete and allows
Searchlight to update our state to reflect the policy changes.
The payload for rbac_policy.delete.end is not as complete. The payload
we receive is:
{
"event_type": "rbac_policy.delete.end",
"payload":
{ "rbac_policy_id": "d7491be9-ee3d-40d7-9880-0ce82c7c12f6" }
}
Since the RBAC policy is being deleted, we cannot query the details of
the policy through the Neutron API using the policy ID. Doing so
results in a race condition where the majority of the time the policy
has already been deleted.
This means we need to store the details of the policy upon
rbac_policy.create.end time, which requires extraneous state in
Searchlight.
We would like a change to the rbac_policy.delete.end payload to
include all policy's details. Mirroring the same information provided
by the rbac_policy.create.end notification:
{
"event_type": "rbac_policy.delete.end",
"payload":
{ "target_tenant": "admin", "tenant_id": "c4b424b17cc04cefa7211b40c5c893c2",
"object_type": "network", "object_id": "64f00d1c-a6b6-4c00-a800-10eb9360a976",
"action": "access_as_shared", "id": "d7491be9-ee3d-40d7-9880-0ce82c7c12f6" }
}
At a bare minimum, we would need "tenant_id", "object_id" and "id" to
be returned.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1612050/+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 1612045] [NEW] Put py34 first in the env order of tox
Public bug reported: When we running the tox, we are may always meeting the problem of "db type could not be determined" on py34, we have to run the py34 first, and then, run py27. So the patch puts py34 first on the tox.ini, which will solve the problem above effectively. ** Affects: horizon Importance: Undecided Assignee: shizhihui (shizhihui) Status: New ** Changed in: horizon Assignee: (unassigned) => shizhihui (shizhihui) -- 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/1612045 Title: Put py34 first in the env order of tox Status in OpenStack Dashboard (Horizon): New Bug description: When we running the tox, we are may always meeting the problem of "db type could not be determined" on py34, we have to run the py34 first, and then, run py27. So the patch puts py34 first on the tox.ini, which will solve the problem above effectively. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1612045/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
Reviewed: https://review.openstack.org/337435
Committed:
https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=ef34175095d92a117fda149ad8a2e216e3a2b78c
Submitter: Jenkins
Branch:master
commit ef34175095d92a117fda149ad8a2e216e3a2b78c
Author: yuyafei
Date: Tue Jul 5 15:21:02 2016 +0800
Add __ne__ built-in function
In Python 3 __ne__ by default delegates to __eq__ and inverts the
result, but in Python 2 they urge you to define __ne__ when you
define __eq__ for it to work properly [1].There are no implied
relationships among the comparison operators. The truth of x==y
does not imply that x!=y is false. Accordingly, when defining
__eq__(), one should also define __ne__() so that the operators
will behave as expected.
[1]https://docs.python.org/2/reference/datamodel.html#object.__ne__
Also fixes spelling errors:resoruces.
Change-Id: Iae4ce0fe84fae810711cc8c3fdb94eb9ca1d772e
Closes-Bug: #1586268
** Changed in: python-keystoneclient
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/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
Fix Released
Status in daisycloud-core:
New
Status in heat:
New
Status in OpenStack Dashboard (Horizon):
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in python-barbicanclient:
New
Status in python-ceilometerclient:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-congressclient:
Fix Released
Status in python-glanceclient:
In Progress
Status in python-heatclient:
Fix Released
Status in python-smaugclient:
Fix Released
Status in python-keystoneclient:
Fix Released
Status in python-manilaclient:
New
Status in python-muranoclient:
Fix Released
Status in python-novaclient:
Fix Released
Status in tempest:
In Progress
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1612029] [NEW] [sr-iov] pci passthrough whitelist doesn't support mult node
Public bug reported:
Description
===
pci_passthrough_whitelist = {"address": ":0a:00.1", "physical_network":
"physnet1"}
If a nova-compute supports multi nodes. The nodes's pci address maybe repeat.
So format above can not describe the situation.
Steps to reproduce
==
None
Expected result
===
None
Suggest Solution
=
pci_passthrough_whitelist = {"address": ":0a:00.1", "node": "",
"physical_network": "physnet1"}
we add node description in pci_passthrough_whitelist.
when nova-compute process pci_passthrough_whitelist per node, ResourceTracker
and PciDeviceStats just process own node's pci_passthrough_whitelist.
PciDeviceSpec doesn't need to add "Node" item. We will pop "Node" of
pci_passthrough_whitelist.
The "Node" is for selection per node.
** Affects: nova
Importance: Undecided
Assignee: xhzhf (guoyongxhzhf)
Status: New
** Tags: pci whitelist
** Changed in: nova
Assignee: (unassigned) => xhzhf (guoyongxhzhf)
** Tags added: pci whitelist
** Description changed:
Description
===
pci_passthrough_whitelist = {"address": ":0a:00.1", "physical_network":
"physnet1"}
If a nova-compute supports multi nodes. The nodes's pci address maybe repeat.
So format above can not describe the situation.
-
Steps to reproduce
==
None
Expected result
===
None
Suggest Solution
=
pci_passthrough_whitelist = {"address": ":0a:00.1", "node": "",
"physical_network": "physnet1"}
we add node description in pci_passthrough_whitelist.
- when nova-compute process pci_passthrough_whitelist per node, ResourceTracker
and PciDeviceStats just process own node's pci_passthrough_whitelist.
+ when nova-compute process pci_passthrough_whitelist per node, ResourceTracker
and PciDeviceStats just process own node's pci_passthrough_whitelist.
PciDeviceSpec doesn't need to add "Node" item. We will pop "Node" of
pci_passthrough_whitelist.
The "Node" is for selection per node.
--
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/1612029
Title:
[sr-iov] pci passthrough whitelist doesn't support mult node
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
pci_passthrough_whitelist = {"address": ":0a:00.1", "physical_network":
"physnet1"}
If a nova-compute supports multi nodes. The nodes's pci address maybe repeat.
So format above can not describe the situation.
Steps to reproduce
==
None
Expected result
===
None
Suggest Solution
=
pci_passthrough_whitelist = {"address": ":0a:00.1", "node": "",
"physical_network": "physnet1"}
we add node description in pci_passthrough_whitelist.
when nova-compute process pci_passthrough_whitelist per node, ResourceTracker
and PciDeviceStats just process own node's pci_passthrough_whitelist.
PciDeviceSpec doesn't need to add "Node" item. We will pop "Node" of
pci_passthrough_whitelist.
The "Node" is for selection per node.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1612029/+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 1610303] Re: l2pop mech fails to update_port_postcommit on a loaded cluster
Reviewed: https://review.openstack.org/352844 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=26bdffb3d73f12833f6fdbdfab6f584f84507693 Submitter: Jenkins Branch:master commit 26bdffb3d73f12833f6fdbdfab6f584f84507693 Author: Oleg Bondarev Date: Tue Aug 9 13:45:26 2016 +0300 Handle deleted ports when creating a list of fdb entries The issue might happen when VMs are intensively created/deleted. With the patch deleted ports will be just skipped. Closes-Bug: #1610303 Change-Id: I32b0de9c452cf973d687c72e8381584012c9f3b4 ** Changed in: neutron 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/1610303 Title: l2pop mech fails to update_port_postcommit on a loaded cluster Status in neutron: Fix Released Bug description: On a cluster where VMs boots and deletes happen pretty intensively following traces can pop up in neutron server log: 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers [req-1b5e9a29-7f7e-48f8-84ee-19ce217cb556 - - - - -] Mechanism driver 'l2population' failed in update_port_postcommit 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers Traceback (most recent call last): 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line 401, in _call_on_drivers 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers getattr(driver.obj, method_name)(context) 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 120, in update_port_postcommit 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers self._update_port_up(context) 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 227, in _update_port_up 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers network_id) 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 176, in _create_agent_fdb 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers fdbs.extend(self._get_port_fdb_entries(binding.port)) 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 45, in _get_port_fdb_entries 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers for ip in port['fixed_ips']] 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers TypeError: 'NoneType' object has no attribute '__getitem__' 2016-08-05 14:08:29.575 9560 ERROR neutron.plugins.ml2.managers 2016-08-05 14:08:29.578 9560 ERROR neutron.plugins.ml2.rpc [req-1b5e9a29-7f7e-48f8-84ee-19ce217cb556 - - - - -] Failed to update device 4c499a14-7211-4714-afa2-95b280d595a2 up This leads to device to being set to Active state and hence Nova timeouts waiting for the interface to be ready. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1610303/+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 1611612] Re: linuxbridge and dhcp agents race removing tap
Reviewed: https://review.openstack.org/353264 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=72720f9aa30169809e41e6dfbafc4e3561716ea5 Submitter: Jenkins Branch:master commit 72720f9aa30169809e41e6dfbafc4e3561716ea5 Author: Darragh O'Reilly Date: Wed Aug 10 05:58:50 2016 + lb-agent: handle exception when bridge slave already removed An exception can happen when a network is deleted because the lb-agent tries to removes the dhcp tap from the bridge at about the same time as the dhcp-agent is deleting the tap. The unhandled exception means the bridge does not get deleted and a log error. Closes-Bug: #1611612 Change-Id: Ia9a6b5fc49e239769e850e9486454e81e3a4b96f ** Changed in: neutron 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/1611612 Title: linuxbridge and dhcp agents race removing tap Status in neutron: Fix Released Bug description: When a network is deleted, an exception can happen because the lb- agent tries to removes the dhcp tap from the bridge at about the same time as the dhcp-agent is deleting the tap. The unhandled exception results in the bridge not getting cleaned up and an error and stacktrace in the logs. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22self.remove_interface%5C%22 Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming res = self.dispatcher.dispatch(message) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch return self._do_dispatch(endpoint, method, ctxt, args) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch result = func(ctxt, **new_args) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 803, in network_delete self.agent.mgr.delete_bridge(bridge_name) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 521, in delete_bridge self.remove_interface(bridge_name, interface) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 568, in remove_interface if bridge_device.delif(interface_name): File "/opt/stack/new/neutron/neutron/agent/linux/bridge_lib.py", line 80, in delif return self._brctl(['delif', self.name, interface]) File "/opt/stack/new/neutron/neutron/agent/linux/bridge_lib.py", line 55, in _brctl return ip_wrapper.netns.execute(cmd, run_as_root=True) File "/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 876, in execute log_fail_as_error=log_fail_as_error, **kwargs) File "/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 138, in execute raise RuntimeError(msg) RuntimeError: Exit code: 1; Stdin: ; Stdout: ; Stderr: device tap1aa0d45a-39 is not a slave of brq6d449049-5c To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611612/+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 1592546] Re: OVSLibTestCase.test_db_find_column_type_list is not isolated
Reviewed: https://review.openstack.org/345296
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=319bc525b408c6df1905e9597da28c2d1ce3020c
Submitter: Jenkins
Branch:master
commit 319bc525b408c6df1905e9597da28c2d1ce3020c
Author: Boden R
Date: Thu Jul 21 15:07:41 2016 +0530
isolate test_db_find_column_type_list
As per the recent gate failures (see bug), it appears
OVSLibTestCase.test_db_find_column_type_list is not isolated
and thus its usage of ovsdb's db_list() and db_find() occasionally
obtain different results.
This patch adds the db_list() and db_find() operations within the
test case to run in a transaction so that we get a single snapshot
of the db results.
In addition this patch undoes the changes from patch set 1 as the
initial changes do not appear to address the issue at hand.
Change-Id: I312076edb6e11f21347831843758894e11d6f56c
Closes-Bug: #1592546
** Changed in: neutron
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/1592546
Title:
OVSLibTestCase.test_db_find_column_type_list is not isolated
Status in neutron:
Fix Released
Bug description:
Spotted in a functional test log:
neutron.tests.functional.agent.test_ovs_lib.OVSLibTestCase.test_db_find_column_type_list(vsctl)
---
Captured traceback:
~~~
Traceback (most recent call last):
File "neutron/tests/functional/agent/test_ovs_lib.py", line 395, in
test_db_find_column_type_list
self.assertEqual(tags_present, len_0_list)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: [{u'tag': 42}, {u'tag': 1}] !=
[{u'tag': 42}, {u'tag': 1}, {u'tag': 1567}]
Note the extra {'tag': 1567}.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1592546/+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 1611991] [NEW] [ovs firewall] Port 23 is open on booted vms with only ping/ssh on 22 allowed.
Public bug reported: Seen on master devstack, ubuntu xenial. Steps to reproduce: 1. Enable ovs firewall in /etc/neutron/plugins/ml2/ml2.conf [securitygroup] firewall_driver = openvswitch 2. Create a security group with icmp, tcp to 22. 3. Boot a VM, assign a floating ip. 4. Check that port 23 can be accessed. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611991 Title: [ovs firewall] Port 23 is open on booted vms with only ping/ssh on 22 allowed. Status in neutron: New Bug description: Seen on master devstack, ubuntu xenial. Steps to reproduce: 1. Enable ovs firewall in /etc/neutron/plugins/ml2/ml2.conf [securitygroup] firewall_driver = openvswitch 2. Create a security group with icmp, tcp to 22. 3. Boot a VM, assign a floating ip. 4. Check that port 23 can be accessed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611991/+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 1611509] Re: lbaasv2 doesn't support "https" keystone endpoint
>From the traceback and code snippet, this is an issue in the neutron-
lbaas codebase. Because of this I have moved this into the neutron bugs
list and tagged it with lbaas.
** Project changed: octavia => neutron
** Tags added: lbaas
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611509
Title:
lbaasv2 doesn't support "https" keystone endpoint
Status in neutron:
New
Bug description:
I am trying to enable lbaasv2 using octavia driver in one of our mitaka
deployment. And we got the error
{code}
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
[req-87d34869-7fec-4269-894b-81a4f1771736 6928cf223a0948699fab55612678cfdc
10d7de26713241a2b623f2028c77e8eb - - -] There was an error in the driver
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin Traceback (most recent call last):
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
line 489, in _call_driver_operation
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin driver_method(context, db_entity)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 118, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
args[0].failed_completion(args[1], args[2])
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin self.force_reraise()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin six.reraise(self.type_,
self.value, self.tb)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 108, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin r = func(*args, **kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 220, in create
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
self.driver.req.post(self._url(lb), args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 150, in post
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return self.request('POST', url,
args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 131, in request
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token =
self.auth_session.get_token()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 618, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
(self.get_auth_headers(auth) or {}).get('X-Auth-Token')
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 597, in
get_auth_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return auth.get_headers(self,
**kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/plugin.py", line 84, in
get_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token = self.get_token(session)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/id
[Yahoo-eng-team] [Bug 1611509] [NEW] lbaasv2 doesn't support "https" keystone endpoint
You have been subscribed to a public bug:
I am trying to enable lbaasv2 using octavia driver in one of our mitaka
deployment. And we got the error
{code}
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
[req-87d34869-7fec-4269-894b-81a4f1771736 6928cf223a0948699fab55612678cfdc
10d7de26713241a2b623f2028c77e8eb - - -] There was an error in the driver
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin Traceback (most recent call last):
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
line 489, in _call_driver_operation
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin driver_method(context, db_entity)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 118, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
args[0].failed_completion(args[1], args[2])
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin self.force_reraise()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin six.reraise(self.type_,
self.value, self.tb)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 108, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin r = func(*args, **kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 220, in create
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
self.driver.req.post(self._url(lb), args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 150, in post
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return self.request('POST', url,
args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 131, in request
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token =
self.auth_session.get_token()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 618, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
(self.get_auth_headers(auth) or {}).get('X-Auth-Token')
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 597, in
get_auth_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return auth.get_headers(self,
**kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/plugin.py", line 84, in
get_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token = self.get_token(session)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py", line 89, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
self.get_access(session).auth_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py", line 135, in
get_access
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin self.auth_ref =
self.get_au
[Yahoo-eng-team] [Bug 1609795] Re: api-ref: glance 'versions' response incorrect
Reviewed: https://review.openstack.org/351185 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=7da4675321683724be7f9f4bb968b979e3ec329d Submitter: Jenkins Branch:master commit 7da4675321683724be7f9f4bb968b979e3ec329d Author: Brian Rosmaita Date: Thu Aug 4 09:29:16 2016 -0400 api-ref: correct versions response example This patch corrects the versions response to be consistent with the current (Mitaka) Images API versions. Change-Id: I57f1caad34af17f9667d16e1574646f378e2c11a Closes-bug: #1609795 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1609795 Title: api-ref: glance 'versions' response incorrect Status in Glance: Fix Released Bug description: Current api-ref is showing 2.4 as CURRENT, but 2.4 has not yet been released. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1609795/+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 1609175] Re: [api] Document query options for GET /projects
Reviewed: https://review.openstack.org/352708 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5740a320f87e12daeb9b5a74bdbe56c784510a94 Submitter: Jenkins Branch:master commit 5740a320f87e12daeb9b5a74bdbe56c784510a94 Author: Tin Lam Date: Tue Aug 9 00:30:36 2016 -0500 api-ref: Add query options to GET /projects API documentation Add the following query options to the api-ref: * parents_as_list (key-only, no value expected) * subtree_as_list (key-only, no value expected) * parents_as_ids (key-only, no value expected) * subtree_as_ids (key-only, no value expected) Change-Id: Ie9362885d57112c81c7141c4238e9e3d5d3e0431 Closes-Bug: #1609175 ** 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 OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1609175 Title: [api] Document query options for GET /projects Status in OpenStack Identity (keystone): Fix Released Bug description: The following query options are missing from the GET /projects API site parents_as_list (key-only, no value expected) subtree_as_list (key-only, no value expected) parents_as_ids (key-only, no value expected) subtree_as_ids (key-only, no value expected) They are already documented in the specs repo: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#get-project To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1609175/+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 1611964] [NEW] SNAT redirect rules should be removed only on Gateway clear.
Public bug reported: SNAT redirect rules should be removed only on Gateway clear and not for a gateway move or gateway reschedule. This would cause the snat_node unreachable by the dvr service ports on the originating node. How to reproduce it. 1. Create a two network node setup (dvr_snat) 2. Create a network 3. Create a subnet 4. Create a router and attach the subnet to the router. 5. Set gateway to the router. 6. Now try to reschedule the router to the secondary node or do a manaul move to a second node. 7. In this case the 'external_gateway_removed" is called through 'external_gateway_updated' function and tries to call snat_redirect_remove. 8. After you move the snat, the router namespace will not have the routing rule for the 'csnat' port. 9. It clears up and you only see the base rules. Expected: root@ubuntu-ctlr:~/devstack# ip rule 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 167772161: from 10.0.0.1/24 lookup 167772161 root@ubuntu-ctlr:~/devstack# ip route s t 167772161 default via 10.0.0.9 dev qr-18deeb39-3b But Actual: root@ubuntu-ctlr:~/devstack# ip rule 0: from all lookup local 32766: from all lookup main 32767: from all lookup default ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-dvr-backlog -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611964 Title: SNAT redirect rules should be removed only on Gateway clear. Status in neutron: New Bug description: SNAT redirect rules should be removed only on Gateway clear and not for a gateway move or gateway reschedule. This would cause the snat_node unreachable by the dvr service ports on the originating node. How to reproduce it. 1. Create a two network node setup (dvr_snat) 2. Create a network 3. Create a subnet 4. Create a router and attach the subnet to the router. 5. Set gateway to the router. 6. Now try to reschedule the router to the secondary node or do a manaul move to a second node. 7. In this case the 'external_gateway_removed" is called through 'external_gateway_updated' function and tries to call snat_redirect_remove. 8. After you move the snat, the router namespace will not have the routing rule for the 'csnat' port. 9. It clears up and you only see the base rules. Expected: root@ubuntu-ctlr:~/devstack# ip rule 0:from all lookup local 32766:from all lookup main 32767:from all lookup default 167772161:from 10.0.0.1/24 lookup 167772161 root@ubuntu-ctlr:~/devstack# ip route s t 167772161 default via 10.0.0.9 dev qr-18deeb39-3b But Actual: root@ubuntu-ctlr:~/devstack# ip rule 0:from all lookup local 32766:from all lookup main 32767:from all lookup default To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611964/+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 1582589] Re: ComputeCapacityFilter always reject irrelevant, self-defined specs
Reviewed: https://review.openstack.org/317306
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=83b59ea6035df173fb206167a4911f512fe22e64
Submitter: Jenkins
Branch:master
commit 83b59ea6035df173fb206167a4911f512fe22e64
Author: OctopusZhang
Date: Tue May 17 08:05:19 2016 +
Allow irrelevant,self-defined specs in ComputeCapacityFilter
For backward compatibility, ComputeCapacityFilter treats extra spec
keys which contain no colons like 'x' the same as 'capabilities:x',
because hoststate doesn't contain attribute like x, this filter always
return False. So it causes conflict with
AggregateInstanceExtraSpecsFilter, and limits user to define extra spec
keys without colons.
This patch solves the conflict and keep it backward compatible.
This patch also joins two lines into one in method host_passes.
Change-Id: Ia9e7c882bcee131e106e67dc46ed9ce1224e4c67
Closes-Bug: #1582589
** 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/1582589
Title:
ComputeCapacityFilter always reject irrelevant,self-defined specs
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Master branch 2016.5.17
When I enabe ComputeCapacityFilter:
If I define a irrelevant specs in flavor like key='x' value='y'
ComputeCapacityFilter will return flase,I can't create instances.
If I define a irrelevant specs like key='mykey:x' value='y'
ComputeCapacityFilter will return True
This means if I don't add a head string and a colon before my real
key, ComputeCapacityFilter doesn't permit me to use it.
If this kind of specs is not allowed,I believe this should be refused
in horizon or api,not in filter.
But when i read test_compute_capabilities_filters.py, I find it is
permitted,but only for ComputeCapacityFilter's specs.
code:
def test_compute_filter_pass_extra_specs_same_as_scope(self):
# Make sure this still works even if the key is the same as the scope
self._do_test_compute_filter_extra_specs(
ecaps={'capabilities': 1},
especs={'capabilities': '1'},
passes=True)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1582589/+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 1610069] Re: there is no detach interface api policy in nova
Reviewed: https://review.openstack.org/352955 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=616102a9ffc05f820a5f44cbcff8941cb228066d Submitter: Jenkins Branch:master commit 616102a9ffc05f820a5f44cbcff8941cb228066d Author: Andrew Laski Date: Tue Aug 9 11:01:26 2016 -0400 Add separate create/delete policies to attach_interface In the v2 API there were separate policy checks for the attach and detach interface actions. This allowed deployers to allow one and not the other. The v2.1 API policy check did not have this split so both had to be enabled/disabled. This patch adds additional checks to allow deployers more granular control. Change-Id: Icf1f0dd12920a2c6126e52a548f3fa4636b431d6 Closes-Bug: 1610069 ** Changed in: nova Status: Triaged => 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/1610069 Title: there is no detach interface api policy in nova Status in OpenStack Compute (nova): Fix Released Bug description: no detach interface policy in nova api To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1610069/+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 1611940] [NEW] vncserver_proxyclient_address changed from stropt to ipopt, breaking backwards compat without deprecation
Public bug reported: The change https://review.openstack.org/#/c/348442/ introduced a backwards incompatible change, specifically at: https://review.openstack.org/#/c/348442/3/nova/conf/vnc.py@68 where vncserver_proxyclient_address was changed from a StrOpt to an IpOpt. This broke backwards compatibility without a proper deprecation notice being introduced and there are especially no release notes that mention this. When running with this new commit, users that configured that parameter as a hostname are now greeted with a stack trace from nova-compute: 2016-08-10 19:26:35.458 10624 CRITICAL nova [req-c235cb33-49c4-4f97-a4a1-0523f134afdc - - - - -] ConfigFileValueError: Value for option vncserver_proxyclient_address is not valid: n59.ci.centos.org is not IPv4 or IPv6 address 2016-08-10 19:26:35.458 10624 ERROR nova Traceback (most recent call last): 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/bin/nova-compute", line 10, in 2016-08-10 19:26:35.458 10624 ERROR nova sys.exit(main()) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/nova/cmd/compute.py", line 78, in main 2016-08-10 19:26:35.458 10624 ERROR nova service.wait() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait 2016-08-10 19:26:35.458 10624 ERROR nova _launcher.wait() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait 2016-08-10 19:26:35.458 10624 ERROR nova status, signo = self._wait_for_exit_or_signal() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 303, in _wait_for_exit_or_signal 2016-08-10 19:26:35.458 10624 ERROR nova self.conf.log_opt_values(LOG, logging.DEBUG) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2591, in log_opt_values 2016-08-10 19:26:35.458 10624 ERROR nova _sanitize(opt, getattr(group_attr, opt_name))) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3022, in __getattr__ 2016-08-10 19:26:35.458 10624 ERROR nova return self._conf._get(name, self._group) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2633, in _get 2016-08-10 19:26:35.458 10624 ERROR nova value = self._do_get(name, group, namespace) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2676, in _do_get 2016-08-10 19:26:35.458 10624 ERROR nova % (opt.name, str(ve))) 2016-08-10 19:26:35.458 10624 ERROR nova ConfigFileValueError: Value for option vncserver_proxyclient_address is not valid: n59.ci.centos.org is not IPv4 or IPv6 address 2016-08-10 19:26:35.458 10624 ERROR nova ** 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/1611940 Title: vncserver_proxyclient_address changed from stropt to ipopt, breaking backwards compat without deprecation Status in OpenStack Compute (nova): New Bug description: The change https://review.openstack.org/#/c/348442/ introduced a backwards incompatible change, specifically at: https://review.openstack.org/#/c/348442/3/nova/conf/vnc.py@68 where vncserver_proxyclient_address was changed from a StrOpt to an IpOpt. This broke backwards compatibility without a proper deprecation notice being introduced and there are especially no release notes that mention this. When running with this new commit, users that configured that parameter as a hostname are now greeted with a stack trace from nova-compute: 2016-08-10 19:26:35.458 10624 CRITICAL nova [req-c235cb33-49c4-4f97-a4a1-0523f134afdc - - - - -] ConfigFileValueError: Value for option vncserver_proxyclient_address is not valid: n59.ci.centos.org is not IPv4 or IPv6 address 2016-08-10 19:26:35.458 10624 ERROR nova Traceback (most recent call last): 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/bin/nova-compute", line 10, in 2016-08-10 19:26:35.458 10624 ERROR nova sys.exit(main()) 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/nova/cmd/compute.py", line 78, in main 2016-08-10 19:26:35.458 10624 ERROR nova service.wait() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait 2016-08-10 19:26:35.458 10624 ERROR nova _launcher.wait() 2016-08-10 19:26:35.458 10624 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait 2016-08-10 19:26:35.458 10624 ERROR nova status, signo = self._wait_for_exit_or_signal() 2016-08-10 19:26:35.458 10624 ERROR nova File
[Yahoo-eng-team] [Bug 1611920] [NEW] l2population mechanism driver should report vlan transparent support
Public bug reported: The l2population mechanism driver does not override the MechanismDriver base class check_vlan_transparent method. This results in the inability to create vlan-transparent networks when the l2populiation mechanism driver is included in the mechanism_drivers configuration list. The l2population mechanism driver has no impact on vlan transparency and thus should report that it is able to support vlan-transparent networks. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611920 Title: l2population mechanism driver should report vlan transparent support Status in neutron: New Bug description: The l2population mechanism driver does not override the MechanismDriver base class check_vlan_transparent method. This results in the inability to create vlan-transparent networks when the l2populiation mechanism driver is included in the mechanism_drivers configuration list. The l2population mechanism driver has no impact on vlan transparency and thus should report that it is able to support vlan-transparent networks. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611920/+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 1605278] Re: Merge python-django 1:1.9.8-1 (main) from Debian unstable (main)
Marking this Won't Fix for now, to get it out of our triage list. Once Yakkety is released, feel free to change the status back to New for reconsideration (and we can ask for consensus again as needed). ** Changed in: python-django (Ubuntu) Status: Confirmed => Won't Fix -- 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/1605278 Title: Merge python-django 1:1.9.8-1 (main) from Debian unstable (main) Status in OpenStack Dashboard (Horizon): New Status in MAAS: New Status in python-django package in Ubuntu: Won't Fix Status in python-django source package in z-series: New Bug description: Please merge python-django 1:1.9.8-1 (main) from Debian unstable (main) Explanation of the Ubuntu delta and why it can be dropped: * SECURITY UPDATE: XSS in admin's add/change related popup - debian/patches/CVE-2016-6186.patch: change to text in django/contrib/admin/static/admin/js/admin/RelatedObjectLookups.js, django/views/debug.py, added to tests in tests/admin_views/admin.py, tests/admin_views/models.py, tests/admin_views/tests.py. - CVE-2016-6186 * Backport b1afebf882db5296cd9dcea26ee66d5250922e53 for ticket 26204 from upstream (1.8.10) to allow dashes in TLDs again (in the URL validator.) LP: #1528710 * Backport b1afebf882db5296cd9dcea26ee66d5250922e53 for ticket 26204 from upstream (1.8.10) to allow dashes in TLDs again (in the URL validator.) LP: #1528710 * SECURITY REGRESSION: is_safe_url() with non-unicode url (LP: #1553251) - debian/patches/CVE-2016-2512-regression.patch: updated to final upstream fix. - CVE-2016-2512 * SECURITY REGRESSION: is_safe_url() with non-unicode url (LP: #1553251) - debian/patches/CVE-2016-2512-regression.patch: force url to unicode in django/utils/http.py, added test to tests/utils_tests/test_http.py. - CVE-2016-2512 * SECURITY UPDATE: malicious redirect and possible XSS attack via user-supplied redirect URLs containing basic auth - debian/patches/CVE-2016-2512.patch: prevent spoofing in django/utils/http.py, added test to tests/utils_tests/test_http.py. - CVE-2016-2512 * SECURITY UPDATE: user enumeration through timing difference on password hasher work factor upgrade - debian/patches/CVE-2016-2513.patch: fix timing in django/contrib/auth/hashers.py, added note to docs/topics/auth/passwords.txt, added tests to tests/auth_tests/test_hashers.py. - CVE-2016-2513 * Merge from Debian unstable. Remaining changes: - debian/patches/pymysql-replacement.patch: Use pymysql as drop in replacement for MySQLdb. - debian/control: Drop python-mysqldb in favor of python-pymysql. * Dropped changes: - debian/patches/99_skip_tests_due_python35.diff: no longer required, python 3.5 is now officially supported in 1.8.6+. All of that was applied in the new Debian version except for the pymysql replacement. Changelog entries since current yakkety version 1.8.7-1ubuntu6: python-django (1:1.9.8-1) unstable; urgency=high * New upstream security release: https://www.djangoproject.com/weblog/2016/jul/18/security-releases/ - CVE-2016-6186: XSS in admin's add/change related popup -- Luke Faraone Tue, 19 Jul 2016 14:15:24 + python-django (1:1.9.7-2) unstable; urgency=medium * Re-upload 1.9.7 to unstable with epoch. -- Chris Lamb Sun, 26 Jun 2016 09:58:19 +0200 python-django (1.10~beta1-1) unstable; urgency=medium [ Chris Lamb ] * New upstream beta release. * Drop fix-25761-add-traceback-attribute.patch; applied upstream. [ Raphaël Hertzog ] * Remove obsolete /etc/bash_completion.d/django_bash_completion on upgrade. Closes: #801744 -- Chris Lamb Sat, 25 Jun 2016 19:17:49 +0200 python-django (1.9.7-1) unstable; urgency=medium [ Raphaël Hertzog ] * New upstream bugfix release. * Bump python-sphinx build dependency to >= 1.3. Closes: #824108 * Drop build dependency on locales. C.UTF-8 that we currently use is part of libc-bin. [ Chris Lamb ] * Remove duplicated "of of" in python-django's README.Debian. -- Raphaël Hertzog Tue, 14 Jun 2016 00:05:22 +0200 python-django (1.9.6-1) unstable; urgency=medium * New upstream bugfix release. -- Chris Lamb Sat, 07 May 2016 07:01:17 +0100 python-django (1.9.5-2) unstable; urgency=medium * Drop the dir_to_symlink transition that was only really needed for upgrades between versions 1.9~rc2 and 1.9.4. Closes: #821789 -- Raphaël Hertzog Wed, 20 Apr 2016 17:47:05 +0200 python-django (1.9.5-1) unstable; urgency=medium * New upstream bugfix release: https://docs.djangoproject.com/en/1.9/releases/1.9.5/ * Fix the
[Yahoo-eng-team] [Bug 1611895] [NEW] Security groups don't work by default in newish kernels
Public bug reported: I recently had some bad experiences running nova-compute on a linux 4.4-series kernel. Specifically, the security-group code properly configured IPtables but the actual rules were completely bypassed -- EVERY port on EVERY instance was open to the outside world. This is presumably due to kernel change described below. I'm unclear on where responsibility sits for activating the proper modprobe; maybe this is something for packagers to care about and not strictly a nova bug. $ git describe --contains 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f v3.18-rc1~115^2~111^2~2 netfilter: bridge: move br_netfilter out of the core Note that this is breaking compatibility for users that expect that bridge netfilter is going to be available after explicitly 'modprobe bridge' or via automatic load through brctl. However, the damage can be easily undone by modprobing br_netfilter. The bridge core also spots a message to provide a clue to people that didn't notice that this has been deprecated. ** 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/1611895 Title: Security groups don't work by default in newish kernels Status in OpenStack Compute (nova): New Bug description: I recently had some bad experiences running nova-compute on a linux 4.4-series kernel. Specifically, the security-group code properly configured IPtables but the actual rules were completely bypassed -- EVERY port on EVERY instance was open to the outside world. This is presumably due to kernel change described below. I'm unclear on where responsibility sits for activating the proper modprobe; maybe this is something for packagers to care about and not strictly a nova bug. $ git describe --contains 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f v3.18-rc1~115^2~111^2~2 netfilter: bridge: move br_netfilter out of the core Note that this is breaking compatibility for users that expect that bridge netfilter is going to be available after explicitly 'modprobe bridge' or via automatic load through brctl. However, the damage can be easily undone by modprobing br_netfilter. The bridge core also spots a message to provide a clue to people that didn't notice that this has been deprecated. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611895/+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 1611892] [NEW] Quickbooks Customer Support Phone Number 1-844-887-9236 (SUPPORT TEAM)
Public bug reported: quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 ** 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/1611892 Title: Quickbooks Customer Support Phone Number 1-844-887-9236 (SUPPORT TEAM) Status in OpenStack Compute (nova): New Bug description: quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks customer support phone number 1-844-887-9236 quickbooks cu
[Yahoo-eng-team] [Bug 1611843] Re: MechanismManager fails to create vlan-transparent network incorrectly with legacy plugins
Setting this to 'invalid' since it isn't actually a bug. According to the original spec [1], this behavior (declining to create a VLAN transparent network in the case that any driver does not have the attribute or has the attribute set to false) is what is expected. [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html#work-items ** Changed in: neutron Status: Incomplete => Invalid ** Tags removed: mitaka-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611843 Title: MechanismManager fails to create vlan-transparent network incorrectly with legacy plugins Status in neutron: Invalid Bug description: As currently implemented, the _check_vlan_transparency method in the MechanismManager class will fail if there is any mechanism driver in the configured mechanism drivers list which does not implement the check_vlan_transparency method. This is because the check for support of vlan transparency currently fails if the call on the mechanism driver check_vlan_transparency returns either False (the mechanism driver explicitly advertises that it does not support vlan transparent networks by overriding the check_vlan_transparency method inherited from the base class) or if it returns 'None' (which is the result of the mechanism driver not overriding the base class check_vlan_transparency method). The initial implementation of vlan-transparency support in the MechanismManager class only raised an error in the event that a driver explicitly returned 'False' from its check_vlan_transparency method (https://review.openstack.org/#/c/158420/18/neutron/plugins/ml2/managers.py), however this logic was changed when the support was moved from core to extension (https://review.openstack.org/#/c/169569/). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611843/+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 1611888] [NEW] 1844-887-9236 Quickbooks Activation Support Phone Number
Public bug reported: 1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone Number1844-887-9236 Quickbooks Activation Support Phone
[Yahoo-eng-team] [Bug 1552971] Re: InstanceList.get_by_security_group_id can run very slow
** Also affects: nova/mitaka Importance: Undecided Status: New ** Changed in: nova Assignee: John Garbutt (johngarbutt) => Paul Griffin (paul-griffin) ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova/mitaka Status: New => Confirmed ** Changed in: nova/mitaka Importance: Undecided => Medium ** Tags added: nova-network -- 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/1552971 Title: InstanceList.get_by_security_group_id can run very slow Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) mitaka series: Confirmed Bug description: The nova.objects.instance.InstanceList class's get_by_security_group_id function calls the db.security_group_get function, which uses the _security_group_get_query() function to generate a query object. That query, by default, joins with the secgroup-rules table, and currently the db.security_group_get function offers no option to avoid joining with the rules. As a result: If a group-source secgroup-rule exists on a security group with a large number of instances and a large number of rules, the db query result will be very large and take multiple seconds to complete, tying up conductor and making the system unresponsive. Since the InstanceList.get_by_security_group_id call only aims to build a list of instances, there is no need in this case to join with the rules, and so the db.security_group_get call should optionally avoid joining with the rules table. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1552971/+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 1611871] [NEW] Timeouts in conductor when updating large sets of security group rules (liberty)
Public bug reported: I have a project with 130+ instances in it. When I set a 'source group' security rule in that project, the rule is never applied on the compute nodes. nova-compute logs include timeout warnings like the one pasted below. This timeout only happens in 'big' cases. If I add a single port to every instance in the project, everything's fine. If I add a 'source group' rule to a project with fewer instances, everything is also fine. It's only the n^2 case for large numbers of n that I get the timeout. Increasing my rpc_response_timeout setting from the default of 60 makes the issue go away. From this I conclude that conductor is not choking, it just really takes longer than 60 seconds. Openstack Liberty, kvm, running on Ubuntu Trusty servers with 3.13-series kernels. Sample stack trace: 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher [req-7af38b91-cfaa-4739-88ec-cbcf10142653 andrew tools - - -] Exception during message handling: Timed out waiting for a reply to message ID 77988fad9aa940aa929752826bde7cdc 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher executor_callback)) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher executor_callback) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 129, in _do_dispatch 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher result = func(ctxt, **new_args) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 470, in decorated_function 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/exception.py", line 89, in wrapped 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher payload) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 195, in __exit__ 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/exception.py", line 72, in wrapped 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher return f(self, context, *args, **kw) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1387, in refresh_instance_security_rules 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher return _sync_refresh() 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 254, in inner 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher return f(*args, **kwargs) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1382, in _sync_refresh 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher return self.driver.refresh_instance_security_rules(instance) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5074, in refresh_instance_security_rules 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher self.firewall_driver.refresh_instance_security_rules(instance) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/virt/firewall.py", line 434, in refresh_instance_security_rules 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher self.do_refresh_instance_rules(instance) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/virt/firewall.py", line 467, in do_refresh_instance_rules 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher ipv4_rules, ipv6_rules = self.instance_rules(instance, network_info) 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/virt/firewall.py", line 399, in instance_rules 2016-08-10 16:30:23.102 9877 ERROR oslo_messaging.rpc.dispatcher ctxt, rule['grantee_group'])) 2016-08-10
[Yahoo-eng-team] [Bug 1611843] [NEW] MechanismManager fails to create vlan-transparent network incorrectly with legacy plugins
Public bug reported: As currently implemented, the _check_vlan_transparency method in the MechanismManager class will fail if there is any mechanism driver in the configured mechanism drivers list which does not implement the check_vlan_transparency method. This is because the check for support of vlan transparency currently fails if the call on the mechanism driver check_vlan_transparency returns either False (the mechanism driver explicitly advertises that it does not support vlan transparent networks by overriding the check_vlan_transparency method inherited from the base class) or if it returns 'None' (which is the result of the mechanism driver not overriding the base class check_vlan_transparency method). The initial implementation of vlan-transparency support in the MechanismManager class only raised an error in the event that a driver explicitly returned 'False' from its check_vlan_transparency method (https://review.openstack.org/#/c/158420/18/neutron/plugins/ml2/managers.py), however this logic was changed when the support was moved from core to extension (https://review.openstack.org/#/c/169569/). ** Affects: neutron Importance: Undecided Status: New ** Tags: mitaka-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611843 Title: MechanismManager fails to create vlan-transparent network incorrectly with legacy plugins Status in neutron: New Bug description: As currently implemented, the _check_vlan_transparency method in the MechanismManager class will fail if there is any mechanism driver in the configured mechanism drivers list which does not implement the check_vlan_transparency method. This is because the check for support of vlan transparency currently fails if the call on the mechanism driver check_vlan_transparency returns either False (the mechanism driver explicitly advertises that it does not support vlan transparent networks by overriding the check_vlan_transparency method inherited from the base class) or if it returns 'None' (which is the result of the mechanism driver not overriding the base class check_vlan_transparency method). The initial implementation of vlan-transparency support in the MechanismManager class only raised an error in the event that a driver explicitly returned 'False' from its check_vlan_transparency method (https://review.openstack.org/#/c/158420/18/neutron/plugins/ml2/managers.py), however this logic was changed when the support was moved from core to extension (https://review.openstack.org/#/c/169569/). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611843/+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 1611834] [NEW] [neutron-fwaas] "Unknown column 'r.tenant_id' in 'where clause'"
Public bug reported: A neutron database upgrade using the master branches results in a traceback that includes "Unknown column 'r.tenant_id' in 'where clause'". The upgrade command is: neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head It seems that it may be related to the following change in neutron- fwaas: commit c3e491cae388713bb175d803de6a216a8816b816 Author: Henry Gessau Date: Thu Jul 14 13:59:31 2016 -0400 Rename DB columns: tenant -> project All occurences of ``tenant_id`` across the neutron database are being renamed to ``project_id``. This neutron-fwaas change accompanies the neutron change: I87a8ef342ccea004731ba0192b23a8e79bc382dc Partially-Implements: blueprint keystone-v3 Change-Id: I984502745629280c033e52f0f1c06fc268fa0255 Meanwhile, neutron_fwaas/db/migration/alembic_migrations/versions/540142f314f4_fwaas_router_insertion.py still has tenant_id in the SQL_STATEMENT: SQL_STATEMENT = ( "insert into firewall_router_associations " "select " "f.id as fw_id, r.id as router_id " "from firewalls f, routers r " "where " "f.tenant_id=r.%s" ) Attached is a full traceback. ** Affects: neutron Importance: Undecided Status: New ** Attachment added: "neutron-db-manage-traceback.log" https://bugs.launchpad.net/bugs/1611834/+attachment/4718404/+files/neutron-db-manage-traceback.log -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611834 Title: [neutron-fwaas] "Unknown column 'r.tenant_id' in 'where clause'" Status in neutron: New Bug description: A neutron database upgrade using the master branches results in a traceback that includes "Unknown column 'r.tenant_id' in 'where clause'". The upgrade command is: neutron-db-manage --config-file /etc/neutron/neutron.conf --config- file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head It seems that it may be related to the following change in neutron- fwaas: commit c3e491cae388713bb175d803de6a216a8816b816 Author: Henry Gessau Date: Thu Jul 14 13:59:31 2016 -0400 Rename DB columns: tenant -> project All occurences of ``tenant_id`` across the neutron database are being renamed to ``project_id``. This neutron-fwaas change accompanies the neutron change: I87a8ef342ccea004731ba0192b23a8e79bc382dc Partially-Implements: blueprint keystone-v3 Change-Id: I984502745629280c033e52f0f1c06fc268fa0255 Meanwhile, neutron_fwaas/db/migration/alembic_migrations/versions/540142f314f4_fwaas_router_insertion.py still has tenant_id in the SQL_STATEMENT: SQL_STATEMENT = ( "insert into firewall_router_associations " "select " "f.id as fw_id, r.id as router_id " "from firewalls f, routers r " "where " "f.tenant_id=r.%s" ) Attached is a full traceback. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611834/+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 1391303] Re: 0.7.5: parse_ssh_config failing in ssh_util.py
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1391303 Title: 0.7.5: parse_ssh_config failing in ssh_util.py Status in cloud-init: Fix Released Bug description: I've been successfully using cloud-init 0.7.4 in a centos 6.5 image I created under an icehouse environment we're running. When I recently created a new centos 6.5 image and yum installed cloud-init (from http://download.fedoraproject.org/pub/epel/6/x86_64) , I got 0.7.5 (cloud-init.x86_64 0:0.7.5-10.el6.centos.2). 0.7.5 is failing in places 0.7.4 wasn't like setting up the ssh keys for the user. I turned on DEBUG for cloud-init console logging in /etc/cloud/cloud.cfg.d/05_logging.cfg: [handler_consoleHandler] class=StreamHandler level=DEBUG formatter=arg0Formatter args=(sys.stderr,) and here's /var/log/cloud-init-output.log http://pastebin.ubuntu.com/8869713/ Attached is a zip file containing copies of my /etc/ssh/sshd_config temporary keys I used that were generated via the OpenStack gui. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1391303/+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 1553158] Re: [SRU] Add cloud-init data source for BigStep
http://paste.ubuntu.com/22917489/ ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1553158 Title: [SRU] Add cloud-init data source for BigStep Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Fix Released Bug description: [Impact] Users on older versions of Ubuntu cannot use the BigStep cloud. [Test Case] 1) Launch an Ubuntu image with the fixed version of cloud-init in the BigStep cloud 2) Successfully SSH in to it [Regression Potential] Low; this adds a new file which is only read on instances that are explicitly configured to read from the BigStep data source. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1553158/+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 1553345] Re: Chef gem installer fails on ubuntu 14.04
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1553345
Title:
Chef gem installer fails on ubuntu 14.04
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Bug description:
Running the "gem" version of the chef install fails on the latest
Ubuntu server 14.04 LTS AMI (ami-fce3c696).
Here is part of my user-data for cloud init:
bootcmd:
- apt-get update && apt-get upgrade cloud-init
- apt-get install build-essential
- apt-get install -q -y <%= find_in_map("SoftwarePropertiesPackage",
ref("LCOSVersion"), "PackageName") %>
- apt-add-repository -y ppa:brightbox/ruby-ng
- echo "Updating package lists..."
- apt-get update -qq
- echo "Installing ruby..."
- apt-get install -q -y ruby<%= find_in_map("RubyVersionToPackageInfo",
ref("AppRubyVersion"), "Version") %>
- apt-get install -q -y ruby<%= find_in_map("RubyVersionToPackageInfo",
ref("AppRubyVersion"), "Version") %>-dev
- update-alternatives --set ruby /usr/bin/ruby<%=
find_in_map("RubyVersionToPackageInfo", ref("AppRubyVersion"), "Version") %>
- update-alternatives --set gem /usr/bin/gem<%=
find_in_map("RubyVersionToPackageInfo", ref("AppRubyVersion"), "Version") %>
- echo "Updating rubygems to latest version..."
- gem update --system --no-rdoc --no-ri
chef:
install_type: gems
version: <%= ref("ChefVersion") %>
...
Here is the output from cloud-init
Mar 4 18:00:04 ip-xxx[CLOUDINIT] util.py[DEBUG]: Running chef
() failed#012Traceback (most
recent call last):#012 File "/usr/lib/python2.7/dist-
packages/cloudinit/stages.py", line 658, in _run_modules#012
cc.run(run_name, mod.handle, func_args, freq=freq)#012 File
"/usr/lib/python2.7/dist-packages/cloudinit/cloud.py", line 63, in
run#012return self._runners.run(name, functor, args, freq,
clear_on_fail)#012 File "/usr/lib/python2.7/dist-
packages/cloudinit/helpers.py", line 197, in run#012results =
functor(*args)#012 File "/usr/lib/python2.7/dist-
packages/cloudinit/config/cc_chef.py", line 99, in handle#012
install_chef_from_gems(cloud.distro, ruby_version, chef_version)#012
File "/usr/lib/python2.7/dist-packages/cloudinit/config/cc_chef.py",
line 128, in install_chef_from_gems#012
distro.install_packages(get_ruby_packages(ruby_version))#012AttributeError:
'str' object has no attribute 'install_packages'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553345/+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 1558069] Re: Login complains "Your environment specifies an invalid locale", doesn't say which locale
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1558069 Title: Login complains "Your environment specifies an invalid locale", doesn't say which locale Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: On login to a brand new trusty machine with all updates applied, the following message appears: _ WARNING! Your environment specifies an invalid locale. This can affect your user experience significantly, including the ability to manage packages. You may install the locales by running: sudo apt-get install language-pack-UTF-8 or sudo locale-gen UTF-8 To see all available language packs, run: apt-cache search "^language-pack-[a-z][a-z]$" To disable this message for all users, run: sudo touch /var/lib/cloud/instance/locale-check.skip _ - The message complains about an invalid locale, but then doesn't tell you what the locale is or what is invalid about it. - The suggested advice "sudo apt-get install language-pack-UTF-8" breaks as follows: ubuntu@z4-dev-black-wap01:~$ sudo apt-get install language-pack-UTF-8 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package language-pack-UTF-8 The above warning needs to be fixed to contain the locate that is invalid, and to provide accurate package names in the advice given to fix it. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1558069/+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 1553815] Re: host keys never restored following metadata api outage
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1553815 Title: host keys never restored following metadata api outage Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Confirmed Status in cloud-init source package in Wily: Won't Fix Status in cloud-init source package in Xenial: Fix Released Bug description: We are running an Openstack cloud and have noticed some unexpected behaviour in our Ubuntu Trusty cloud instances created by Nova. We have observed that if a previously initialised instance (e.g. DataSourceOpenstack has already been run) is rebooted while the metadata api is not available (i.e. 169.254.169.264 is unreachable), cloud-init will retry a few times then switch to DataSourceNone and regenerate host keys. # Boot instance under normal conditions ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. # Stop neutron metadata api service and reboot instance (observing that host keys were regenerated) ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/iid-datasource-none ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. Generating public/private rsa key pair. So far so good since we expect this behaviour, but now we reboot this instance with the metadata api is once again reachable. Cloud-init rightly selects the original DataSourceOpenstack instance but it does nothing since it already ran once (and it is set to only run once). The problem here is that the original host keys are never restored so any client connecting to that instance will have no option to accept the new host keys along with MITM attack warning. ubuntu@vm1:~$ sudo reboot ... ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 Surely we could find a way for cloud-init to know that if if the current DataSourceOpenstack uuid matches its previously run uuid, then it can check that the host keys are consistent with the original run. @smoser suggested in a side discussion that dmidecode info could perhaps be used since the Openstack instance uuid can be found there: ubuntu@vm1:~$ sudo dmidecode -t system # dmidecode 2.12 SMBIOS 2.8 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: OpenStack Foundation Product Name: OpenStack Nova Version: 13.0.0 Serial Number: ba5f7371-fd4c-a25e-132f-3dd1e5b92e93 UUID: CD535BC4-9C2F-4D31-8903-0EDE59C7EF95 Wake-up Type: Power Switch SKU Number: Not Specified Family: Virtual Machine Handle 0x2000, DMI type 32, 11 bytes System Boot Information Status: No errors detected If cloud-init kept a copy of previous host keys prior to regenerating them, it could presumably use this info to know when to safely restore the original host keys. Since it is not inconceivable for the metadata api to become unreachable for a brief period (perhpas during an upgrade), i think we really need to make cloud-init more tolerant of this circumstance. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1553815/+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 1404311] Re: [SRU] gce metadata api doesn't properly stream binary data
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1404311 Title: [SRU] gce metadata api doesn't properly stream binary data Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Utopic: Fix Released Status in cloud-init source package in Vivid: Fix Released Bug description: [IMPACT] Due to limitations in GCE, binary user-data is mangled when sent as user-data. [FIX] Allow user to declare binary encoding on user-data. [VERIFICATION] 1. Create pristine image from -proposed 2. For step 6 3. Boot GCE instance w/ normal user-data, i.e.: $ cat user-data #cloud-config ssh_import_id: [utlemming] $ gcloud compute instances create \ --metadata-from-file user-data=user-data 4. Confirm that user-data was parsed properly 5. GZIP user-data, and encode using base64: gzip -c user-data.txt | base64 > user-data.b64 6. Boot GCE instance w/ user-data.b64 and character encoding meta-data set: $ gcloud compute instances create \ --metadata-from-file user-data=user-data.b64 \ --metadata user-data-encoding=base64 7. Confirm that user-data was consumed; attach /var/log/cloud-init.log to report. [RISK] If a user sets the user-data-encoding to base64, but does not provide base64 data the instance will fail to provision. However, since the user has to explicitly setup the circumstances, it is low risk. [ORIGINAL REPORT] The GCE datasource uses the long hostname. Hostnames longer than 64 characters can break several tools. While implementing the GCE provider for Juju we found that the metadata API breaks when trying to retrieve certain binary formats. In our case the gz of user-data. The API only streams out the first 5 bytes, encounters what it preceives as a EOF/nil character and truncates the rest of the request. We've opened an issue with Google directly, but in the meantime a work around is to allow an explicit encoding to be set for the user-data field of the GCE metadata. This will allow use to base64 encode the binary blob, which the API returns the entire contents of without issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1404311/+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 1383794] Re: [SRU] GCE datasource should use the short hostname
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1383794 Title: [SRU] GCE datasource should use the short hostname Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Utopic: Fix Released Bug description: [IMPACT] Since GCE FQDN are usually longer than 64-characters, several hi-profile tools like Java and Hadoop may break. [FIX] Per GCE's recommendation, Linux instances should use the short hostname over the FQDN. This change sets the system hostname to the short name. [VERIFICATION] 1. Install new cloud-init from proposed 2. Re-run cloud-config: * 14.04/14.10: cloud-init single -n set_hostname --frequency=always * 12.04: cloud-init-cfg set_hostname always 3. Check to make sure that the short name is used for /etc/hostname [RISK] This is a very low risk change. The actual change is a single line, and has test cases for 14.04 and 14.10. Further, since this change is only in the GCE datasource, it only affects GCE instances. [ORIGINAL REPORT] The GCE datasource uses the long hostname. Hostnames longer than 64 characters can break several tools. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1383794/+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 1391695] Re: IPv6 network info translation support for rhel
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1391695 Title: IPv6 network info translation support for rhel Status in cloud-init: Fix Released Bug description: Cloud-init currently doesn’t parse ipv6 network information from the OpenStack Nova's disk.config. Here’s the code that does the parsing: https://github.com/number5/cloud-init/blob/master/cloudinit/distros/rhel.py#L65-L98 Whereas, the IPv6 network-scripts/ifcfg file is expected to be: http://www.cyberciti.biz/faq/rhel-redhat-fedora-centos-ipv6-network-configuration/ The conversion is missing a lot of options. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1391695/+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 1507526] Re: Failed to load user-data on RHEV/AltCloud in wily due to bad udevadm args
This is fixed in cloud-init 0.7.7. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1507526 Title: Failed to load user-data on RHEV/AltCloud in wily due to bad udevadm args Status in cloud-init: Fix Released Bug description: Using cloud-init 0.7.7 in the wily cloud-images daily: [ 12.493421] cloud-init[872]: 2015-10-19 10:14:26,302 - util.py[WARNING]: Failed command: /sbin/udevadm settle --quiet --timeout=5 --exit-if-exists=/dev/fd0 [ 12.493665] cloud-init[872]: Unexpected error while running command. [ 12.497403] cloud-init[872]: Command: ['/sbin/udevadm', 'settle', '--quiet', '--timeout=5', '--exit-if-exists=/dev/fd0'] [ 12.500557] cloud-init[872]: Exit code: 1 [ 12.500799] cloud-init[872]: Reason: - [ 12.501036] cloud-init[872]: Stdout: '' [ 12.501270] cloud-init[872]: Stderr: 'Option -q no longer supported.\n' [ 12.501504] cloud-init[872]: 2015-10-19 10:14:26,318 - util.py[WARNING]: Failed accessing user data. Note: this is not actually *on* RHEV, I fake it to have cloud-init load user data from a floppy drive for testing purposes, which works fine in 14.04 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1507526/+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 1198297] Re: RFE: seed /dev/urandom with random data from metadata service when available
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1198297 Title: RFE: seed /dev/urandom with random data from metadata service when available Status in cloud-init: Fix Released Bug description: If a cloud provider offers random data to instances via a metadata service, like, oh, say, https://review.openstack.org/#/c/14550/, cloud-init should take advantage of that and seed /dev/urandom with it. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1198297/+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 1566824] Re: phone_home module should allow fqdn to be posted
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1566824 Title: phone_home module should allow fqdn to be posted Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: Currently the phone_home module allows for the hostname of a machine to be posted but not the FQDN. I'm happy to make this change myself but I cannot work out how to submit the patch through launchpad. I'll update this if I work it out. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1566824/+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 1355343] Re: cloud-init writes sources.list without newline at end of file
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1355343 Title: cloud-init writes sources.list without newline at end of file Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: This happens on Utopic. Trusty is fine. Steps to reproduce: sudo lxc-create -t ubuntu-cloud -n utopic -- -F -s daily -r utopic sudo lxc-start-ephemeral -o trusty -n test -d sudo lxc-attach -n test -- login -f root Examine /etc/apt/sources.list inside the host. For example, "cat /etc/apt/sources.list" shows the subsequent prompt at the end of the last line instead of on a fresh line. "vim /etc/apt/sources.list" says "noeol". Expected: newline at end of file, following Unix convention. Actual: no newline at end of file. Impact: messes up my local script that does trivial manipulations (adds a local repository). I've examined the sources.list shipped with the image, and it doesn't have this problem and the sources.list I see after startup looks radically different (matching the template in /etc/cloud/...). So it seems to me that the templating mechanism inside cloud-init is causing this. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: cloud-init 0.7.6~bzr992-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-7.26-generic 3.13.1 Uname: Linux 3.13.0-7-generic x86_64 NonfreeKernelModules: veth xt_conntrack ipt_REJECT ip6table_filter ip6_tables ebtable_nat ebtables overlayfs xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables dm_crypt kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel microcode psmouse serio_raw aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd floppy ApportVersion: 2.14.5-0ubuntu4 Architecture: amd64 Date: Mon Aug 11 18:00:26 2014 PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1355343/+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 1569018] Re: [FFe] support lxc bridge configuration
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1569018 Title: [FFe] support lxc bridge configuration Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: recent changes to lxd added configuration of the lxd bridge. We'd like to enable that in cloud-init. The change allows the user to put config in cloud-config that will basically map to the debconf keys and thus configure their lxd bridge and lxd init on first boot making it immediately useful. it should be safe for regression in that if there is no lxd bridge config, no change in code path will be taken. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1569018/+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 1597875] Re: Networking issues with the SmartOS datasource under Xenial
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1597875 Title: Networking issues with the SmartOS datasource under Xenial Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Committed Bug description: Under xenial (16.04) on a VM with more than one IP/interface cloud- init fails to setup additional IPS. So for instance if I provision and VM with two IPs, cloud-init only sets up one IP (which is typcially the main/public IP). I believe the underlying issue has to do with changes in systemd and how interfaces are now named in the new world. Specifically, you can no longer assume "eth" prefixed interface names. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1597875/+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 1574113] Re: curtin/maas don't support multiple (derived) archives/repositories with custom keys
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1574113
Title:
curtin/maas don't support multiple (derived) archives/repositories
with custom keys
Status in cloud-init:
Fix Released
Status in curtin:
Confirmed
Status in MAAS:
Triaged
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
In Progress
Bug description:
In a customer environment I have to deploy using offline resources (no
internet connection at all), so I created apt mirror and MAAS images
mirror. I configured MAAS to use the local mirrors and I'm able to
commission the nodes but I'm not able to deploy the nodes because
there is no way to add gpg key of the local repo in target before the
'late' stage'.
Using curtin I'm able to add the key but too late, in fact according
with http://bazaar.launchpad.net/~curtin-
dev/curtin/trunk/view/head:/curtin/commands/install.py#L52 "late"
stage is executed after "curthooks" this prevent to add the key.
I checked also apt_config function in curthooks.py I did't see code
that add the key for each mirror.
It should be possible to add gpg public of the repository in maas.
--
configs/config-000.cfg
--
#cloud-config
debconf_selections:
maas: |
cloud-init cloud-init/datasources multiselect MAAS
cloud-init cloud-init/maas-metadata-url string
http://100.107.231.164/MAAS/metadata/
cloud-init cloud-init/maas-metadata-credentials string
oauth_token_key=8eZmzQWSSQzsUkaLnE&oauth_token_secret=LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP&oauth_consumer_key=htwDZJFtmv2YvQXhUW
cloud-init cloud-init/local-cloud-config string
apt_preserve_sources_list: true\nmanage_etc_hosts: false\nmanual_cache_clean:
true\nreporting:\n maas: {consumer_key: htwDZJFtmv2YvQXhUW, endpoint:
'http://100.107.231.164/MAAS/metadata/status/node-61b6987c-07a7-11e6-9d23-5254003d2515',\n
token_key: 8eZmzQWSSQzsUkaLnE, token_secret:
LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP,\ntype: webhook}\nsystem_info:\n
package_mirrors:\n - arches: [i386, amd64]\nfailsafe: {primary:
'http://archive.ubuntu.com/ubuntu', security:
'http://security.ubuntu.com/ubuntu'}\nsearch:\n primary:
['http://100.107.231.166/']\n security: ['http://100.107.231.166/']\n -
arches: [default]\nfailsafe: {primary:
'http://ports.ubuntu.com/ubuntu-ports', security:
'http://ports.ubuntu.com/ubuntu-ports'}\nsearch:\n primary:
['http://ports.ubuntu.com/ubuntu-ports']\n security:
['http://ports.ubuntu.com/ubuntu-ports']\n
late_commands:
maas: [wget, '--no-proxy',
'http://100.107.231.164/MAAS/metadata/latest/by-id/node-61b6987c-07a7-11e6-9d23-5254003d2515/',
'--post-data', 'op=netboot_off', '-O', '/dev/null']
apt_key: ["curtin", "in-target", "--", "sh", "-c", "/usr/bin/wget
--no-proxy -qO - http://100.107.231.166/magellan.key | apt-key add -"]
power_state:
mode: reboot
apt_mirrors:
ubuntu_archive: http://100.107.231.166//
ubuntu_security: http://100.107.231.166//
- curtin end of log --
Leaving 'diversion of /etc/init/ureadahead.conf to
/etc/init/ureadahead.conf.disabled by cloud-init'
Setting up swapspace version 1, size = 8388604 KiB
no label, UUID=e2fe91bc-91e9-4e43-b50f-209dfcf04089
Get:1 http://100.107.231.166 trusty InRelease [17.7 kB]
Get:2 http://100.107.231.166 trusty-updates InRelease [17.7 kB]
Get:3 http://100.107.231.166 trusty-security InRelease [17.7 kB]
Ign http://100.107.231.166 trusty InRelease
Get:4 http://100.107.231.166 trusty/main amd64 Packages [412 kB]
Ign http://100.107.231.166 trusty-updates InRelease
Ign http://100.107.231.166 trusty-security InRelease
Get:5 http://100.107.231.166 trusty/restricted amd64 Packages [20 B]
Get:6 http://100.107.231.166 trusty/universe amd64 Packages [20 B]
Get:7 http://100.107.231.166 trusty/multiverse amd64 Packages [20 B]
Get:8 http://100.107.231.166 trusty-updates/main amd64 Packages [33.0 kB]
Get:9 http://100.107.231.166 trusty-updates/restricted amd64 Packages [20 B]
Get:10 http://100.107.231.166 trusty-updates/universe amd64 Packages [20 B]
Get:11 http://100.107.231.166 trusty-updates/multiverse amd64 Packages [20 B]
Get:12 http://100.107.231.166 trusty-security/main amd64 Packages [6,578 B]
Get:13 http://100.107.231.166 trusty-security/restricted amd64 Packages [20 B]
Get:14 http://100.107.231.166 trusty-security/universe amd64 Packages [20 B]
Get:15 http://100.107.231.166 trusty-security/multiverse amd64 Packages [20 B]
Fetched 505 kB in 0s (3,772 kB/s)
Reading package lists...
W: GPG error: http://100.107.231.166 trusty InRelease: The following
signatures couldn't be verified because the p
[Yahoo-eng-team] [Bug 1554152] Re: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1554152 Title: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in pollinate package in Ubuntu: Fix Released Status in pollinate source package in Trusty: Fix Committed Bug description: cloud-init runs pollinate via 'cc_seed_random.py' config job. Some points a.) in addition to seeding via pollinate seed_random will seed the random device with data from the datasource if it is provided (azure and openstack provide a random seed for this purpose) b.) we really want seed_random to run before ssh , so that keys are generated with good entropy in place. c.) seed_random runs early via 'init_modules' mostly to accomplish 'b'. Unfortunately, network is not guaranteed at this point if the datasource is a 'local' datasource (such as config drive). e.) in many cases pollinate will not have access to https://entropy.ubuntu.com (due to firewall or disconnected) f.) in xenial, cloud-init reports events to maas as they occur, and when this module fails, it reports that. g.) maas marks nodes as failed deployment when cloud-init reports failure End result, if you dont have access to entropy.ubuntu.com, then you fail deployment. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: cloud-init 0.7.7~bzr1176-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3 Uname: Linux 4.4.0-10-generic x86_64 NonfreeKernelModules: ufs qnx4 hfsplus hfs minix ntfs msdos ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Mon Mar 7 17:30:00 2016 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1554152/+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 1548772] Re: mkfs fails on interactive input when no partition is used
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1548772 Title: mkfs fails on interactive input when no partition is used Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: When an attempt is made to format a block device directly on a cloud platform like Azure as below, this attempt fails as follows: fs_setup: - label: data device: /dev/sdc filesystem: ext4 2016-02-23 11:01:50,344 - util.py[WARNING]: Failed during filesystem operation Failed to exec of '['/sbin/mkfs.ext4', '/dev/sdc', '-L', 'data']': Unexpected error while running command. Command: ['/sbin/mkfs.ext4', '/dev/sdc', '-L', 'data'] Exit code: 1 Reason: - Stdout: '/dev/sdc is entire device, not just one partition!\nProceed anyway? (y,n) ' Stderr: 'mke2fs 1.42.9 (4-Feb-2014)\n' It looks like the -F option needs to be added to mkfs.ext4 to force mkfs to be non-interactive. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1548772/+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 1539317] Re: default user should be in the lxd group
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1539317 Title: default user should be in the lxd group Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: Since LXD is installed by default on the cloud-images, the default user should be put in the lxd group. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1539317/+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 1536964] Re: Remove obsolete syslog.target dep from systemd services
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1536964 Title: Remove obsolete syslog.target dep from systemd services Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: systemd removed syslog.target some versions ago. Also it's use was not necessary since some years. The recommendation to use syslog.target was removed in version 35, see http://www.freedesktop.org/wiki/Software/systemd/syslog/. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1536964/+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 1576273] Re: CloudStack datasource fails to find DHCP lease if IPv6 present
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1576273
Title:
CloudStack datasource fails to find DHCP lease if IPv6 present
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Bug description:
The CloudStack data source looks in /var/lib/dhcp for DHCP lease files
and compares the timestamps.
If you have a dhclient.leases and dhclient6.leases file present it
will look in the dhclient6.leases file for a DHCP server to connect
to.
The fix for this is rather simple, change a if-statement so that it
checks if the leases file starts with 'dhclient.'
if file_name.startswith("dhclient.") and \
(file_name.endswith(".lease") or file_name.endswith(".leases")):
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1576273/+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 1594546] Re: no need to write systemd.link files
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1594546 Title: no need to write systemd.link files Status in cloud-init: Fix Released Bug description: When fixing bug 1579130 , we made cloud-init rename devices itself, rather than relying on the systemd.link files to do that. cloud-init was still writing .link files like: /etc/systemd/network/50-cloud-init-ens2.link That leads to just a confusing situation as cloud-init will trump any renaming systemd does in all cases. We'd like to get to a place where cloud-init allows the user to later customize the name of the devices in a supported manner, but for the moment, these files only create confusion. Related Bugs: * bug 1579130: need to support renaming of devices in container and on first boot To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1594546/+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 1582323] Re: Commissioning fails when competing cloud metadata resides on disk
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1582323 Title: Commissioning fails when competing cloud metadata resides on disk Status in cloud-init: Fix Released Status in MAAS: Triaged Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: A customer reused hardware that had previously deployed a RHEL Overcloud-controller which places metadata on the disk as a legitimate source, that cloud-init looks at by default. When the newly enlisted node appeared it had the name of "overcloud-controller-0" vs. maas- enlist, pulled from the disk metadata which had overridden MAAS' metadata. Commissioning continually failed on all of the nodes until the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f data or dd zeros to disk). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1582323/+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 1565638] Re: Cloud-init on Xenial won't deploy compressed content in "write_files" - says DecompressionError: Not a gzipped file
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1565638
Title:
Cloud-init on Xenial won't deploy compressed content in "write_files"
- says DecompressionError: Not a gzipped file
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Bug description:
I'm trying to deploy an Amazon EC2 instance using cloud-init.
When I'm compressing the files in the write_files section, the cloud-
init process doesn't write the files, and I get the following error in
the cloud-init.log :
Apr 3 16:27:16 ubuntu [CLOUDINIT] handlers.py[DEBUG]: finish:
init-network/config-write-files: FAIL: running config-write-files with
frequency once-per-instance
Apr 3 16:27:16 ubuntu [CLOUDINIT] util.py[WARNING]: Running module
write-files ()
failed
Apr 3 16:27:16 ubuntu [CLOUDINIT] util.py[DEBUG]: Running module write-files
() failed
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 393, in
decomp_gzip
return decode_binary(gh.read())
File "/usr/lib/python3.5/gzip.py", line 274, in read
return self._buffer.read(size)
File "/usr/lib/python3.5/gzip.py", line 461, in read
if not self._read_gzip_header():
File "/usr/lib/python3.5/gzip.py", line 409, in _read_gzip_header
raise OSError('Not a gzipped file (%r)' % magic)
OSError: Not a gzipped file (b"b'")
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 735, in
_run_modules
freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run
return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run
results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_write_files.py",
line 39, in handle
write_files(name, files, log)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_write_files.py",
line 74, in write_files
contents = extract_contents(f_info.get('content', ''), extractions)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_write_files.py",
line 98, in extract_contents
result = util.decomp_gzip(result, quiet=False)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 400, in
decomp_gzip
raise DecompressionError(six.text_type(e))
cloudinit.util.DecompressionError: Not a gzipped file (b"b'")
I've verified that the cloud init I'm submitting does encode the files
correctly by running this ruby code on the cloud-init YAML file:
> File.write("test.gz",
YAML.load(File.read("test.init"))["write_files"].first["content"])
Then:
$ file test.gz
test.gz: gzip compressed data, last modified: Mon Apr 4 06:55:53 2016, max
compression, from Unix
$ python
Python 2.7.11+ (default, Mar 30 2016, 21:00:42)
[GCC 5.3.1 20160330] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> with gzip.open('test.gz', 'rb') as f:
... file_content = f.read()
... print file_content
...
I've never implemented this with trusty, so I'm not sure how cloud-
init on trusty handles that.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1565638/+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 1455233] Re: read_seeded broken
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1455233
Title:
read_seeded broken
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Vivid:
Fix Released
Bug description:
=== Begin SRU Information ===
[Impact]
cloud-init cannot read a "seed". Many of the data-sources allow a seed from
a url. This is useful in testing, especially with the NoCloud seed from the
command line.
One of the functions in cloud-init simply does not work with python-3,
and the patch makes that work. Patch is applied to upstream and
present in wily.
[Test Case]
Run the attached test-bug-1455233. Without the patch applied, the system
will boot and show error like in the serial.log:
util.py[WARNING]: Getting data from failed
Additionally, a simple test case can be done more directly by simply running
$ echo "my-userdata" > user-data
$ echo "instance-id: FOO" > meta-data
$ python -m SimpleHTTPServer 8999 &
$ python3 -c 'from cloudinit import util;
print(util.read_seeded("http://localhost:8999/";, retries=0))'
127.0.0.1 - - [09/Jun/2015 01:24:05] "GET /meta-data HTTP/1.1" 200 -
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 842, in
read_seeded
if md_resp.ok():
AttributeError: 'str' object has no attribute 'ok'
The added test case in the build process pushes the code through this
function.
[Regression Potential]
This code was 100% broken in python3, so likelyhood of regression is very low.
=== End SRU Information ===
util.read_seeded uses load_tfile_or_url, but then treats the return
value as if it was a response.
this regressed in revno 1067.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1455233/+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 1478103] Re: need support for configuring syslog
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1478103 Title: need support for configuring syslog Status in cloud-init: Fix Released Status in MAAS: Fix Committed Bug description: in order to instruct a host to easily log syslog information to another system, we need to add a cloud-config format for this. The format to use looks like this: ## syslog module allows you to configure the systems syslog. ## configuration of syslog is under the top level cloud-config ## entry 'syslog'. ## ## "remotes" ## remotes is a dictionary. items are of 'name: remote_info' ## name is simply a name (example 'maas'). It has no importance other than ## for cloud-init merging configs ## ## remote_info is of the format ##* optional filter for log messages ## default if not present: *.* ##* optional leading '@' or '@@' (indicates udp or tcp). ## default if not present (udp): @ ## This is rsyslog format for that. if not present, is '@' which is udp ##* ipv4 or ipv6 or hostname ## ipv6 addresses must be encoded in [::1] format. example: @[fd00::1]:514 ##* optional port ## port defaults to 514 ## ## Example: #cloud-config rsyslog: remotes: # udp to host 'maas.mydomain' port 514 maashost: maas.mydomain # udp to ipv4 host on port 514 maas: "@[10.5.1.56]:514" # tcp to host ipv6 host on port 555 maasipv6: "*.* @@[FE80::0202:B3FF:FE1E:8329]:555" To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1478103/+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 1461242] Re: cloud-init does not generate ed25519 keys
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1461242 Title: cloud-init does not generate ed25519 keys Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Utopic: Invalid Status in cloud-init source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Bug description: Cloud-init does not generate ed25519 hosts keys as expected. Ubuntu 14.04 and later have SSH configurations expecting ed25519 keys by default. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1461242/+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 1532072] Re: cloud-init fails with UnicodeDecodeError
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1532072
Title:
cloud-init fails with UnicodeDecodeError
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Yakkety:
Fix Released
Bug description:
I'm running the latest Ubuntu Wily AMI on EC2 (ami-15b7e87f). When the
instance boots up cloud-init fails with the following exception:
[ 69.519513] cloud-init[901]: 2016-01-08 03:43:00,902 - util.py[WARNING]:
failed of stage init
[ 69.551842] cloud-init[901]: failed run of stage init
[ 69.552029] cloud-init[901]:
[ 69.552427] cloud-init[901]: Traceback (most recent call last):
[ 69.552591] cloud-init[901]: File "/usr/bin/cloud-init", line 509, in
status_wrapper
[ 69.557342] cloud-init[901]: ret = functor(name, args)
[ 69.557524] cloud-init[901]: File "/usr/bin/cloud-init", line 272, in
main_init
[ 69.557695] cloud-init[901]: init.update()
[ 69.557859] cloud-init[901]: File
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in update
[ 69.558020] cloud-init[901]: self._store_userdata()
[ 69.558185] cloud-init[901]: File
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 360, in
_store_userdata
[ 69.558344] cloud-init[901]: processed_ud = self.datasource.get_userdata()
[ 69.558502] cloud-init[901]: File
"/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 83, in
get_userdata
[ 69.558660] cloud-init[901]: self.userdata =
self.ud_proc.process(self.get_userdata_raw())
[ 69.558832] cloud-init[901]: File
"/usr/lib/python3/dist-packages/cloudinit/user_data.py", line 96, in process
[ 69.560273] cloud-init[901]: self._process_msg(convert_string(blob),
accumulating_msg)
[ 69.560440] cloud-init[901]: File
"/usr/lib/python3/dist-packages/cloudinit/user_data.py", line 342, in
convert_string
[ 69.560603] cloud-init[901]: data =
util.decode_binary(util.decomp_gzip(raw_data))
[ 69.560764] cloud-init[901]: File
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 86, in decode_binary
[ 69.560926] cloud-init[901]: return blob.decode(encoding)
[ 69.561094] cloud-init[901]: UnicodeDecodeError: 'utf-8' codec can't
decode byte 0x8d in position 0: invalid start byte
I've tracked it down to the following commit:
https://github.com/number5/cloud-
init/commit/a7835683afd19f1ae291cc93f008320a7820b24f#diff-
a543026d533dadf4f39b57d1f65dc1b7R339
The user-data that is set on our instances is beyond my control.
Here's a sample of it:
b'\x8dV\xd9\x8e\xa3H\x16\xfd\x95\x92_\x9d\x99\xec\x06\xf2\x8d\xc5,\x06\x8c1;\xa3\xd1\x88}3;\x18C\xab\xff\xbd\xa32kT\xea\x87\x1e\r\x0f!\xc5\xb9q\xe3\x9es\xe3@\xf0\xc7!\n\xa7\xd4\xbe\xab\x87\xcfC1\xcf\xfd\'\x04=\xba8|\x14\xdd4\x7f\x9eh\x1a\x86\xa2\xa5|$\x13\x14\xe6i;\x9b\xe9\xf8LG\xe8\xf0v\x98\xe6p\x9c\x97\xde*\x9b\xb4[\x00\x1ewm2\x1d>O0\xfcv\xa8\xd3M\x0b[\x9002\x8f\xbc\x1b\xcb\xb9h\xaea\x93\x82\n\xe6\xd2z\x04L\x83\xfcy\\\xa6\xf9\x1fV\xdd\x14\xd9\x03K\x9at\x0e\xf9p\x0e\x0f\x9f\x7f\x00\x92M\xd4u\x1f\xa0\xf8Tv\xed\xc7\xd4\xa7q\x99\x95\xf1G\x02\xe2\x1f?\t\xcf\x00\x06\xa9\x13\x06\x04|/~\xffb\xfc>\xa6\x8f\x14(|_\xa6\xf7\x14\x81\x88\x0f\x04~\xd7\xf9w0\xc20\x05aT\x96d\x08\x1a\xa1\x08\x89#d\x16#h\x1ag\x08\x15\xa5p\x8a\x00)\xa7\x13uJ\xe2\x08\x8e\x00\x9b_\x0c\xa6\xaf\x0e|de\x0b\x88\xf7c\xd9\xce\xa0\xea\x89BI\x14\xa7\t\xb0%\r#\x08E\xa2
!\\\xa7\x8f\xaf.\xa5\x890v\r\xfb\x95\x0f\x16\x03\xe5\xe9\xef\x06\x9a\xf1X\xf6\xf3\x7f`\x10\xf8\x95\xf3E\x9b\x99\xa6\xb4\x89\x1e\x9b\xfa[\xda\xff\xaf\x8a\x8e\x93,\xca\xd2\x88"\xf18\xa2\x93\x98\xa4q\x84HQ\x92"C\x9c\x86\xd18\xc6\x12\x84\xa4\x888\xcc2\x1c\x8dOx\x94\xd11\ng\t\t\xc0\x0cO\xc2\xdfj\xcb\x16\xd0l\xe3\xf4\x1f\x1a>\xfdf\xfd\x9d\xf0\xed\x0f\xe7\xfb\x94@\xf0\xef\xc4\x0e\x7f\xbe\x1d\x96)\xb5\x96\xb6M\x1fB7J\xc0o\x87\xcf\x9f\xfd\xf8;~i\xa6\xff\xc2e\xdevc\xca\xa5\xe3\xfc\xb3z8\xa7\\\x91\xc65\x08g\xe1c\x02\xf1\xf4\x11Ns\x19\xcb\rh\x0b\xd7\xb5Y\x99/\xe3\x17599|\xa2\'\x14\xc1q\n\x98\xedk\xe7[7\xce_
\x8a\xbf}y\xfd6v\xaf\xed\x1b\xc5O\x04\x8d\xbd\x1d\xaaf\xfa5\'P\xf2\xcb\xc8\xe6\x0c\xea\x1f>\xffu\xa8@\xd5\xb7\x03\xb4`G\xd2`\xc0#\xff\x1c\xd8\x9f\x03c0R\xe0\xbe\x8a\x18\xbb\xf7\xfe\n\xe6\x8e\x9c\xc9\x18\xc9\xff\x8cW\x15\xc71~\xb7\xf2\xb9\xaf(\xab\xcf\xb2\xccy`\x8a3\xcb\x186\xc3\xca2\x9b<\x8c\xa3\x0f{\xbcBs\xa1\xe3\xd7\x1b\x8f3F\xe7c\xbd\xc9\xcbF\xe3(\xbc\xff\xcaP}h\xdc\xba\xa4\xb6a\xeco\x02\\\r\xba\x0c#\xf4\x0c\x05K\xbe\xd1\x1a^a\n){w\xcev\x90M\xb1\x10\xbb|m\xa41\x85\x9e\x1bo\x19\xdd9\xf2\x83\x92^\xafDPn\xd1\xcd\xec\xdcj\x12\xb4\xda;z\xce\xee\x19\xa5\xb0\xab\x0c\xd1\x93\xf3\xadsc\xc92\xb5\xc8\x8b\x0c\xe2dq\x86\xd8\xe3}\
[Yahoo-eng-team] [Bug 1496960] Re: webhook reporter posts url encoded data not json data
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1496960 Title: webhook reporter posts url encoded data not json data Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: Ricardo was trying to tie reporting into maas and found that it is posting things like: timestamp=1442509672.620882&result=SUCCESS&origin=cloudinit&description=running+modules+for+final&event_type=finish&name=modules-final rather than posting json data representing that same stuff, as curtin is doing. Need to change cloud-init to be in line with what curtin is doing and maas expects. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: cloud-init 0.7.7~bzr1144-0ubuntu1 ProcVersionSignature: User Name 4.2.0-7.7-generic 4.2.0 Uname: Linux 4.2.0-7-generic x86_64 ApportVersion: 2.18.1-0ubuntu1 Architecture: amd64 Date: Thu Sep 17 17:57:03 2015 Ec2AMI: ami-0589 Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: None Ec2Ramdisk: None PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1496960/+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 1463373] Re: [SRU] cc_apt_configure does not work with python3
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1463373 Title: [SRU] cc_apt_configure does not work with python3 Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Bug description: The way cc_apt_configure.py writes out the script to fetch GPG keys breaks when using Python 3. [Impact] GPG keys specified in cloud configuration cannot be checked. [Test Case] Specify a key in a source in the apt_sources cloud config key, and ensure that there aren't warnings about it in /var/log/cloud-init.log after boot. [Regression Potential] This part of the feature is completely broken at the moment, so very little chance to regress. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1463373/+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 1465436] Re: growpart does not respect devices list
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1465436
Title:
growpart does not respect devices list
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Bug description:
From
http://bazaar.launchpad.net/~cloud-init-dev/cloud-
init/trunk/view/head:/cloudinit/config/cc_growpart.py#L279
devices = util.get_cfg_option_list(cfg, "devices", ["/"])
if not len(devices):
log.debug("growpart: empty device list")
return
The full config is passed rather than the already acquired growpart
config, causing the devices list not to be found and subsequently
ignored. Needs to be updated from "cfg" to "mycfg" and then seems to
work correctly.
Apologies for lack of formatting, I haven't worked in Launchpad
previously.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1465436/+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 1513609] Re: easily disable cloud-init
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1513609 Title: easily disable cloud-init Status in cloud-init: Fix Released Bug description: cloud-init should be easy to disable. cloud-init by design does slow down system boot for 2 reasons a.) by design, to offer users the ability to do things at defined points in boot and block other things b.) by nature of being python code and loading libraries and just being "one more thing" that occurs in boot. We should fix performance wherever we can, but shoudl also make it such that cloud-init can be installed (in an image) and not negatively affect boot performance if none of its functionality is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1513609/+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 1487877] Re: write_files errors out on non ascii content
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1487877
Title:
write_files errors out on non ascii content
Status in cloud-init:
Fix Released
Bug description:
When trying to add content in the write_files an error is thrown:
2015-08-23 10:37:54,678 - util.py[WARNING]: Running write_files
() failed
The cloud-config file is attached.
When searching for the root cause, found to be an error raised in line 95 of
cloudinit/config/cc_write_files.py
"""
def extract_contents(contents, extraction_types):
result = str(contents)
for t in extraction_types:
"""
The conversion from unicode to string throws an exception. I tested this by
using a plain script:
"""
#!/bin/python
import yaml
f=open("/etc/salt-cloud/cloud.deploy.d/userdata_strbug.txt","r")
conf = yaml.load(f)
print "Testing write_files bug ... "
for c in conf['write_files']:
print "Content to string: ",str(c['content'])
"""
With this output:
"""
Testing write_files bug ...
Content to string:
Traceback (most recent call last):
File "utils/misc/test-yaml-bug.py", line 9, in
print "Content to string: ",str(c['content'])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position
1087: ordinal not in range(128)
"""
Line 40 of the configuration file, is the offending one, it's a
comment.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1487877/+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 1514407] Re: NoCloud provider fails with empty ds_cfg
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1514407 Title: NoCloud provider fails with empty ds_cfg Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: get_data() accesses ds_cfg which can be None. Make sure it is at least an empty dict (as in the Openstack data source). Attached patch fixes this as does the branch at: https://code.launchpad.net/~agx/cloud-init/nocloud To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1514407/+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 1568150] Re: xenial lxc containers not starting
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1568150 Title: xenial lxc containers not starting Status in cloud-init: Fix Released Status in juju-core: Invalid Status in cloud-init package in Ubuntu: Fix Released Bug description: When deploying a xenial lxc container to a xenial host, the container fails during cloud-init with the following error in the container's /var/log/cloud-init-output.log: 2016-04-08 21:07:05,190 - util.py[WARNING]: failed of stage init-local failed run of stage init-local Traceback (most recent call last): File "/usr/bin/cloud-init", line 515, in status_wrapper ret = functor(name, args) File "/usr/bin/cloud-init", line 250, in main_init init.fetch(existing=existing) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 318, in fetch return self._get_data_source(existing=existing) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 227, in _get_data_source ds.check_instance_id(self.cfg)): File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceNoCloud.py", line 220, in check_instance_id dirs=self.seed_dirs) AttributeError: 'DataSourceNoCloudNet' object has no attribute 'seed_dirs' Trusty containers start just fine. Using juju 1.25.5 and MAAS 1.9.2 Commands to reproduce: juju bootstrap --constraints "tags=juju" --upload-tools --show-log --debug juju set-constraints "tags=" juju add-machine --series xenial juju deploy --to lxc:1 local:xenial/ubuntu ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1568150/+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 1427939] Re: oauthlib code does not adjust timestamp
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1427939 Title: oauthlib code does not adjust timestamp Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: in the python3 port, we moved from python-oauth to python-oauthlib. That change lost the functionality added to solve bug 978127 (http://pad.lv/978127). We really need to have this in order to do oauth from systems that do not have a clock that retains time across reboots. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1427939/+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 1353008] Re: MAAS Provider: LXC did not get DHCP address, stuck in "pending"
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1353008 Title: MAAS Provider: LXC did not get DHCP address, stuck in "pending" Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Trusty: Fix Released Bug description: === Begin SRU Information === This bug causes lxc containers created by the ubuntu-cloud template (lxc-create -t ubuntu-cloud) to sometimes not obtain an IP address, and thus not correctly boot to completion. The bug is in an assumption by cloud-init that /run is mounted before the cloud-init-local job is run. The fix is very simply to guarantee that it is via modification to its upstart 'start on'. When booting with an initramfs /run will be mounted before /, so the race condition is not possible. Thus, the failure case is only either in non-initramfs boot (which is very unlikely) or in lxc boot. The lxc case seems only to occur very rarely, somewhere well under one percent of the time. [Test Case] A test case is written at [1] that launches many instances in an attempt brute force find the error. However, I've not been able to make it fail. The original bug reporter has been running with the 'start on' change and has seen no errors since. We will request the original bug reporter to apply the uploaded changes and run through their battery. [Regression Potential] The possibility for regression here is in the second boot of an instance. The following scenario is a change of behavior: * the user boots an instance with NoCloud or ConfigDrive in ds=local mode * user changes /etc/network/interfaces in a way that would cause static-networking to not be emitted on subsequent boot * user reboots Now, instead of a quick boot, the user may see cloud-init-nonet blocking on network coming up. This would be a uncommon scenario, and the broken-etc-network- interfaces scenario is already one that causes timeouts on boot. -- [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/cloud-init-test/view/head:/tests/lxc-test-new-instance === End SRU Information === Note, that after I went onto the system, it *did* have an IP address. 0/lxc/3: agent-state: pending instance-id: juju-machine-0-lxc-3 series: trusty hardware: arch=amd64 cloud-init-output.log snip: Cloud-init v. 0.7.5 running 'init' at Mon, 04 Aug 2014 23:57:12 +. Up 572.29 seconds. ci-info: +++Net device info+++ ci-info: ++--+---+---+---+ ci-info: | Device | Up | Address |Mask | Hw-Address| ci-info: ++--+---+---+---+ ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . | ci-info: | eth0 | True | . | . | 00:16:3e:34:aa:57 | ci-info: ++--+---+---+---+ ci-info: !!!Route info failed Cloud-init v. 0.7.5 running 'modules:config' at Mon, 04 Aug 2014 23:57:12 +. Up 572.99 seconds. Cloud-init v. 0.7.5 running 'modules:final' at Mon, 04 Aug 2014 23:57:14 +. Up 574.42 seconds. Cloud-init v. 0.7.5 finished at Mon, 04 Aug 2014 23:57:14 +. Datasource DataSourceNoCloudNet [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]. Up 574.54 seconds syslog on system, showing DHCPACK 1 second later: root@juju-machine-0-lxc-3:/home/ubuntu# grep DHCP /var/log/syslog Aug 4 23:57:13 juju-machine-0-lxc-3 dhclient: DHCPREQUEST of 10.96.3.173 on eth0 to 255.255.255.255 port 67 (xid=0x1687c544) Aug 4 23:57:13 juju-machine-0-lxc-3 dhclient: DHCPOFFER of 10.96.3.173 from 10.96.0.10 Aug 4 23:57:13 juju-machine-0-lxc-3 dhclient: DHCPACK of 10.96.3.173 from 10.96.0.10 Aug 5 05:28:15 juju-machine-0-lxc-3 dhclient: DHCPREQUEST of 10.96.3.173 on eth0 to 10.96.0.10 port 67 (xid=0x1687c544) Aug 5 05:28:15 juju-machine-0-lxc-3 dhclient: DHCPACK of 10.96.3.173 from 10.96.0.10 Aug 5 11:15:00 juju-machine-0-lxc-3 dhclient: DHCPREQUEST of 10.96.3.173 on eth0 to 10.96.0.10 port 67 (xid=0x1687c544) Aug 5 11:15:00 juju-machine-0-lxc-3 dhclient: DHCPACK of 10.96.3.173 from 10.96.0.10 It appears in every case, cloud-init init-local has failed very early visible in juju logs /var/lib/juju/containers//console.log: Traceback (most recent call last): File "/usr/bin/cloud-init", line 618, in sys.exit(main()) File "/usr/bin/cloud-init", line 614, in main get_uptime=True, func=functor, args=(name, args)) File "/usr/lib/python2.7/dist-packages/cloudinit/util.py", line 1875, in log_
[Yahoo-eng-team] [Bug 1449318] Re: power_state does not take effect when runcmd errors
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1449318 Title: power_state does not take effect when runcmd errors Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Wily: Won't Fix Status in cloud-init source package in Xenial: Fix Released Bug description: When the runcmd errors the power-state-change does not take effect and the instance is not powered off. AMI ID: ubuntu-vivid-15.04-amd64-server-20150422 (ami-2d10241d) Instance launched on EC2 using awscli: $ aws --region us-west-2 ec2 run-instances --image-id ami-2d10241d --instance-type t2.medium --security-groups ssh-http-https --user-data file://fail.cfg Minimal fail.cfg cloud config: ``` #cloud-config power_state: mode: poweroff runcmd: - set -e - python3 -c "raise Exception" ``` Longer fail.cfg used for retrieving logs: ``` #cloud-config output: all: '| tee -a /var/log/cloud-init-output.log' power_state: mode: poweroff bootcmd: - cloud-init-per once ssh-users-ca echo "TrustedUserCAKeys /etc/ssh/users_ca.pub" >> /etc/ssh/sshd_config runcmd: - set -e - python3 -c "raise Exception" write_files: - path: /etc/ssh/users_ca.pub content: ``` To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1449318/+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 1596690] Re: restoring from datasource without dsmode causes stacktrace
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1596690 Title: restoring from datasource without dsmode causes stacktrace Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: On reboot, if cloud-init found a cached /var/lib/cloud/instance/obj.pkl it would restore from it. If that class did not have a 'dsmode', then main would stack trace like: | "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 530, in status_wrapper | ret = functor(name, args) | File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 247, in main_init | if mode == sources.DSMODE_NETWORK and init.datasource.dsmode != mode: | AttributeError: 'DataSourceAzureNet' object has no attribute 'dsmode' This would affect upgrade and reboot on any datasource that did not have a dsmode previously. That list is cloudinit/sources/DataSourceAzure.py cloudinit/sources/DataSourceBigstep.py cloudinit/sources/DataSourceCloudStack.py cloudinit/sources/DataSourceDigitalOcean.py cloudinit/sources/DataSourceEc2.py cloudinit/sources/DataSourceGCE.py cloudinit/sources/DataSourceMAAS.py cloudinit/sources/DataSourceNone.py cloudinit/sources/DataSourceOVF.py cloudinit/sources/DataSourceSmartOS.py The non-broken datasources then were the ones that previously had a dsmode: cloudinit/sources/DataSourceAltCloud.py cloudinit/sources/DataSourceCloudSigma.py cloudinit/sources/DataSourceConfigDrive.py cloudinit/sources/DataSourceNoCloud.py cloudinit/sources/DataSourceOpenNebula.py cloudinit/sources/DataSourceOpenStack.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1596690/+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 1387340] Re: 'output' directive not honored (/var/log/cloud-init-output.log missing)
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1387340 Title: 'output' directive not honored (/var/log/cloud-init-output.log missing) Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Utopic: Won't Fix Status in cloud-init source package in Vivid: Fix Released Bug description: launched a utopic instance, expected to see /var/log/cloud-init-output.log, and did not. 0.7.6 regressed the honoring of this. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: cloud-init 0.7.6~bzr1022-0ubuntu1 [modified: usr/lib/python2.7/dist-packages/cloudinit/util.py] ProcVersionSignature: User Name 3.16.0-23.31-generic 3.16.4 Uname: Linux 3.16.0-23-generic x86_64 ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 Date: Wed Oct 29 19:36:05 2014 Ec2AMI: ami-00bc Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: aki-0002 Ec2Ramdisk: ari-0002 PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1387340/+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 1597699] Re: cc_mcollective.py fails on Ubuntu16.04
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1597699 Title: cc_mcollective.py fails on Ubuntu16.04 Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: Begin SRU Template [Impact] mcollective usage via cloud-init is not possible. [Test Case] launch instance with cloud-config containing 'mcollective' entry. $ cat >user-data <<"EOF" #cloud-config mcollective: conf: main_collective: mcollective collectives: mcollective libdir: /usr/share/mcollective/plugins logfile: /var/log/mcollective.log loglevel: debug daemonize: 1 direct_addressing: 1 ttl: 4294957 securityprovider: psk plugin.psk: unset identity: 2 connector: rabbitmq plugin.rabbitmq.vhost: mcollective plugin.rabbitmq.pool.size: 1 plugin.rabbitmq.pool.1.host: 10.10.0.2 plugin.rabbitmq.pool.1.port: 61613 plugin.rabbitmq.pool.1.user: mcollective plugin.rabbitmq.pool.1.password: ScwpVo8egrZ0OmT6sRmp9zEA plugin.rabbitmq.heartbeat_interval: 30 factsource: yaml plugin.yaml: /etc/mcollective/facts.yaml EOF $ keyname=brickies; image=$image; $ openstack server create \ --key-name=$keyname --flavor=m1.small \ --image=$image --user-data=user-data mcollective-test0 # then ssh in and a.) verify mcollective package is installed $ dpkg-query --show mcollective mcollective 2.6.0+dfsg-2.1 b.) verify mcollective service is running $ systemctl status mcollective c.) grep WARN /var/log/cloud-init.log && echo FAIL [Regression Potential] low to none. This has been unfortunately broken since wily. [Other Info] End SRU Template How to reproduce: #cat /etc/issue.net Ubuntu 16.04 LTS #( cd /var/lib/cloud/ && rm -rf * ) #cloud-init -d init #grep ^mcollective: -A25 instance/user-data.txt mcollective: conf: main_collective: mcollective collectives: mcollective libdir: /usr/share/mcollective/plugins logfile: /var/log/mcollective.log loglevel: debug daemonize: 1 direct_addressing: 1 ttl: 4294957 securityprovider: psk plugin.psk: unset identity: 2 connector: rabbitmq plugin.rabbitmq.vhost: mcollective plugin.rabbitmq.pool.size: 1 plugin.rabbitmq.pool.1.host: 10.10.0.2 plugin.rabbitmq.pool.1.port: 61613 plugin.rabbitmq.pool.1.user: mcollective plugin.rabbitmq.pool.1.password: ScwpVo8egrZ0OmT6sRmp9zEA plugin.rabbitmq.heartbeat_interval: 30 factsource: yaml plugin.yaml: /etc/mcollective/facts.yaml #cloud-init -d single --name mcollective The log will contain Jun 30 08:26:43 node-2 [CLOUDINIT] util.py[DEBUG]: Running module mcollective () failed#012Traceback (most recent call last):#012 File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 739, in _run_modules#012freq=freq)#012 File "/usr/lib/python3/dist- packages/cloudinit/cloud.py", line 70, in run#012return self._runners.run(name, functor, args, freq, clear_on_fail)#012 File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run#012results = functor(*args)#012 File "/usr/lib/python3/dist- packages/cloudinit/config/cc_mcollective.py", line 83, in handle#012 mcollective_config.write(contents)#012 File "/usr/lib/python3/dist- packages/configobj.py", line 2126, in write#012 outfile.write(output_bytes)#012TypeError: string argument expected, got 'bytes' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1597699/+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 1315501] Re: cloud-init does not use interfaces.d in trusty
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1315501 Title: cloud-init does not use interfaces.d in trusty Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: Hi, Reference/context: https://ask.openstack.org/en/question/28297/cloud- init-nonet-waiting-and-fails/ The trusty image provided by http://cloud-images.ubuntu.com/trusty/ contains an eth0 interface configured as dhcp in /etc/network/interfaces.d/eth0.cfg. When I boot this image in an Openstack non-dhcp networking environment, cloud-init configures the static IP provided by Neutron directly in /etc/network/interfaces (not interfaces.d). This means I now have two eth0 devices configured, in two different files. Booting 20 VMs with the same image yields around 50-60% of VMs that are not reachable by network. Soft rebooting a VM in this state or doing and "ifdown eth0 && ifup eth0" will make it ping. I removed the the eth0 interface file in /etc/network/interfaces.d/eth0.cfg from the image, booted another round of VMs and all of them worked fine. Now, I see three possible outcomes: - If eth0 is present in /etc/network/interfaces.d, cloud-init configures/re-configures that interface - If eth0 is present in /etc/network/interfaces.d, cloud-init deletes it and configures /etc/network/interfaces - Ubuntu cloud images ships without eth0 being configured by default To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+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 1428495] Re: Does not enable ssh even with ssh_enabled: True
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1428495 Title: Does not enable ssh even with ssh_enabled: True Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: The latest cloud images from vivid with cloud-init 0.7.7~bzr1076-0ubuntu1 now stop enabling ssh by default, as they create an /etc/ssh/ssh_not_to_be_run stamp file. Aside from the fact that there was no warning about it and it's not documented in the changelog or documentation or anywhere, re-enabling also does not seem to work. I found the new "ssh_enabled" key in cloudinit/config/cc_snappy.py, but setting it in my user-data (for generating a local seed iso) does not work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1428495/+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 1258619] Re: New debug module that prints some information about the instance
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1258619 Title: New debug module that prints some information about the instance Status in cloud-init: Fix Released Bug description: This is a new debug module thats supposed to print out some information about the instance being created. The module can be included at any stage of the process - init/config/final To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1258619/+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 1295223] Re: seedfrom cmdline option broken in 0.7.5
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1295223 Title: seedfrom cmdline option broken in 0.7.5 Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: the ability to pass in 'seedfrom' on the kernel command line to the nocloud datasource was broken with the vendor-data changes. The fix is simple. recreate is just bo boot a image with 'ds=nocloud-net;seedfrom=http://.' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1295223/+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 1428139] Re: merge snappy support
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1428139 Title: merge snappy support Status in cloud-init: Fix Released Bug description: lp:~smoser/ubuntu/vivid/cloud-init/vivid-snappy has the code that is in the 'snappy' version of cloud-init as found in snappy builds. need to pull that into cloud-init for ubuntu archive to get rid of the differences. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1428139/+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 1445143] Re: fail to process user-data with cloud-config-archive
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1445143
Title:
fail to process user-data with cloud-config-archive
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Vivid:
Fix Released
Bug description:
launching an instance with this user-data causes the stack trace further below
#cloud-config-archive:
- content: |
#cloud-config
chpasswd: {expire: false}
manage_etc_hosts: true
password: ubuntu
Apr 16 17:20:29 ubuntu [CLOUDINIT] util.py[DEBUG]: Consuming user data
failed!#012Traceback (most recent call last):
File "/usr/bin/cloud-init", line 280, in main_init
init.consume_data(PER_ALWAYS)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 496, in
consume_data
self._consume_userdata(frequency)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 566, in
_consume_userdata
self._do_handlers(user_data_msg, c_handlers_list, frequency)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 489, in
_do_handlers
walk_handlers(excluded)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 472, in
walk_handlers
handlers.walk(data_msg, handlers.walker_callback, data=part_data)
File "/usr/lib/python3/dist-packages/cloudinit/handlers/__init__.py", line
248, in walk
payload = util.fully_decoded_payload(part)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 126, in
fully_decoded_payload
return cte_payload.decode(charset, errors='surrogateescape')
TypeError: decode() argument 1 must be str, not Charset
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: cloud-init 0.7.7~bzr1088-0ubuntu3 [modified:
usr/lib/python3/dist-packages/cloudinit/util.py]
ProcVersionSignature: User Name 3.19.0-14.14-generic 3.19.3
Uname: Linux 3.19.0-14-generic x86_64
ApportVersion: 2.17.1-0ubuntu1
Architecture: amd64
Date: Thu Apr 16 17:48:07 2015
Ec2AMI: ami-02ed
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: aki-0002
Ec2Ramdisk: ari-0002
PackageArchitecture: all
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1445143/+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 1575055] Re: check_instance_id() error on reboots when using config-drive
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1575055 Title: check_instance_id() error on reboots when using config-drive Status in cloud-init: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: Problem Description = When using a config-drive to provide meta-data to cloud-init on ubuntu (for Linux guest running in KVM for z Systems) we get a check_instance_id() error whenever we soft reboot after the (successful) initial boot. The error shows: [5.283203] cloud-init[1637]: Cloud-init v. 0.7.7 running 'init-local' at Sat, 23 Apr 2016 00:50:58 +. Up 5.25 seconds. [5.283368] cloud-init[1637]: 2016-04-22 20:50:58,839 - util.py[WARNING]: failed of stage init-local [5.286659] cloud-init[1637]: failed run of stage init-local [5.286770] cloud-init[1637]: [5.286849] cloud-init[1637]: Traceback (most recent call last): [5.286924] cloud-init[1637]: File "/usr/bin/cloud-init", line 520, in status_wrapper [5.286998] cloud-init[1637]: ret = functor(name, args) [5.287079] cloud-init[1637]: File "/usr/bin/cloud-init", line 250, in main_init [5.287152] cloud-init[1637]: init.fetch(existing=existing) [5.287225] cloud-init[1637]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch [5.287298] cloud-init[1637]: return self._get_data_source(existing=existing) [5.287371] cloud-init[1637]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in _get_data_source [5.287445] cloud-init[1637]: ds.check_instance_id(self.cfg)): [5.287518] cloud-init[1637]: TypeError: check_instance_id() takes 1 positional argument but 2 were given [5.287592] cloud-init[1637]: [FAILED] Failed to start Initial cloud-init job (pre-networking). The failure of the init-local pre-networking does seem to lead to a boot up delay as cloud-init tries to search for networking outside of the already saved networking data. Otherwise the error is purely cosmetic as later init modules find (or let existing IP configuration take over) and bring up the correct interfaces. The original problem was found outside of openstack with stand-alone cloud-config iso images. But have been able to reproduce the problem within an openstack ICM environment. Team has had some success getting around the problem by patching the check_instance_id function in /usr/lib/python3/dist- packages/cloudinit/sources/DataSourceConfigDrive.py so that it accepted an extra argument, ex: ubuntu@markvercd:~$ sudo cat check_instance_id.patch --- /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py 2016-04-06 15:29:59.0 + +++ /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py.new 2016-04-11 22:53:47.799867139 + @@ -155,7 +155,7 @@ return True -def check_instance_id(self): +def check_instance_id(self,somecfg): # quickly (local check only) if self.instance_id is still valid return sources.instance_id_matches_system_uuid(self.get_instance_id()) ubuntu@markvercd:~$ ---uname output--- Linux k6mpathcl.pokprv.stglabs.ibm.com 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:31:26 UTC 2016 s390x s390x s390x GNU/Linux Machine Type = KVM guest on a z13 (2827-732) LPAR Steps to Reproduce = 1) set up ubuntu guest image with cloud-init 2) pass in iso image with cloud-config data in cdrom device 3) boot up successfully with cloud-config data 4) attempt a soft reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1575055/+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 1590104] Re: network config from datasource overrides network config from system
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1590104 Title: network config from datasource overrides network config from system Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Bug description: network configuration in system config should override that found as provided by a datasource. The order of precedence should be: datasource system config kernel command line When juju creates lxc containers they want to be in control of networking and do not want cloud-init to configure networking either from the datasource (lxc's template provided nocloud) or from fallback. They are specifying that configuration directly in /etc/network/interfaces. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: cloud-init 0.7.7~bzr1212-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-23.41-generic 4.4.10 Uname: Linux 4.4.0-23-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Tue Jun 7 18:16:09 2016 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1590104/+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 1577982] Re: ConfigDrive: cloud-init fails to configure network from network_data.json
This is fixed in cloud-init 0.7.7 ** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1577982 Title: ConfigDrive: cloud-init fails to configure network from network_data.json Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly configure the network from network_data.json found in ConfigDrive. When instance boots, network is configured fine until next reboot where it falls back to dhcp. The /etc/network/interfaces.d/50-cloud-init.cfg file has the following content when instance is initially booted, this could explain why dhcp is used on second boot: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp When debugging, if this line in stages.py [1] is commented, we can see that cloud-init initially copy the /etc/network/interfaces file found in the configdrive (the network template injected by Nova) and isn't using the network config found in network_data.json. But later it falls back to "dhcp" and rewrites yet again the network config. I also found that within self._find_networking_config(), it looks like no datasource is found at this point. This could be because cloud-init is still in "local" dsmode and then refuses to use the network config found in the ConfigDrive. (triggering the "dhcp" fallback logic) Manually forcing "net" dsmode makes cloud-init configure /etc/network/interfaces.d/50-cloud-init.cfg properly with network config found in the ConfigDrive. However no gateway is configured and so, instance doesn't respond to ping or SSH. At that point, I'm not sure what's going on and how I can debug further. Notes: * The image used for testing uses "net.ifnames=0". Removing this config makes things much worst. (no ping at all on first boot) * Logs, configs and configdrive can be found attached to this bug report. [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud- init/trunk/view/head:/cloudinit/stages.py#L604 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1577982/+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 1602373] Re: cloud-init doesn't always land files that one expects
This is fixed in cloud-init 0.7.7
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
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/1602373
Title:
cloud-init doesn't always land files that one expects
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Bug description:
Begin SRU Template
[Impact]
Injected files functionality of OpenStack's config drive is broken.
[Test Case]
== Reproduce broken functionality ==
$ echo "hi mom" > my-file.txt
$ cat > "user-data" <<"EOF"
#!/bin/sh
logfile=/run/my.log
file="/my-file.txt"
if [ -e "$file" ]; then
( echo "=== PASS: file $file " ; cat $file ) | tee -a $logfile
exit 0
else
echo "=== FAIL: no file $file " | tee -a $logfile
exit 0
fi
EOF
openstack server create --key-name=brickies --flavor=m1.small \
--config-drive=1 --image=$img \
--user-data=user-data --file=/my-file.txt=my-file.txt \
injected-file0
The launched system will have a file in /run/my.log that shows 'FAIL'
and will not have /my-file.txt on disk.
== See Fix ==
# enable proposed
$ cat > enable-proposed <<"EOF"
#!/bin/sh
set -e
rel=$(lsb_release -sc)
awk '$1 == "deb" && $2 ~ /ubuntu.com/ {
printf("%s %s %s-proposed main universe\n", $1, $2, rel); exit(0) };
' "rel=$rel" /etc/apt/sources.list |
tee /etc/apt/sources.list.d/proposed.list
EOF
$ sudo sh ./enable-proposed
$ sudo apt-get update
$ sudo apt-get install cloud-init
# Remove /var/lib/cloud and /var/log/cloud-init* to remove state
# and indicate this is a new instance on reboot
$ sudo rm -Rf /var/lib/cloud /var/log/cloud-init*
$ sudo reboot
Now ssh back in after reboot, you should
a.) have /my-file.txt
b.) see PASS in /run/my.log
c.) see mention of the 'injected file' in /var/log/cloud-init.log
[Regression Potential]
Regression potential on Ubuntu should be very small.
End SRU Template
Trove launches instances using the servers.create() API with some
files. Trove provides a dictionary of files that it wants on the
instance and most of the time this works. Nova passes them to the
launched VM as metadata on config drive.
Sometimes though, it doesn't.
When injection fails, I see a cloud-init.log that looks like this:
https://gist.github.com/amrith/7566d8fef4b6e813cca77e5e3b1f1d5a
When injection succeeds, I see a cloud-init.log that looks like this:
https://gist.github.com/amrith/50d9e3050d88ec51e13b0a510bd718c3
Observe that the one that succeeds properly injects three files:
/etc/injected_files (which is something I added just for debugging)
/etc/trove/conf.d/... two files here ...
On a machine where this injection failed:
root@m10:/tmp/zz/openstack/content# ls -l /etc/trove
total 4
drwxr-xr-x 2 amrith root 4096 Jul 12 16:55 conf.d
root@m10:/tmp/zz/openstack/content# ls -l /etc/trove/conf.d/
total 4
root@m10:/tmp/zz/openstack/content#
Clearly, no files made it over. Yet, the files are definitely there on
the config drive ...
I've mounted the config drive.
root@m10:/tmp/zz/openstack/content# mount | grep zz
/dev/sr0 on /tmp/zz type iso9660 (ro,relatime)
root@m10:/tmp/zz/openstack/content# cd /tmp/zz
root@m10:/tmp/zz# find .
.
./ec2
./ec2/2009-04-04
./ec2/2009-04-04/meta-data.json
./ec2/latest
./ec2/latest/meta-data.json
./openstack
./openstack/2012-08-10
./openstack/2012-08-10/meta_data.json
./openstack/2013-04-04
./openstack/2013-04-04/meta_data.json
./openstack/2013-10-17
./openstack/2013-10-17/meta_data.json
./openstack/2013-10-17/vendor_data.json
./openstack/2015-10-15
./openstack/2015-10-15/meta_data.json
./openstack/2015-10-15/network_data.json
./openstack/2015-10-15/vendor_data.json
./openstack/2016-06-30
./openstack/2016-06-30/meta_data.json
./openstack/2016-06-30/network_data.json
./openstack/2016-06-30/vendor_data.json
./openstack/content
./openstack/content/
./openstack/content/0001
./openstack/content/0002
./openstack/latest
./openstack/latest/meta_data.json
./openstack/latest/network_data.json
./openstack/latest/vendor_data.json
root@m10:/tmp/zz# cd openstack/latest/
root@m10:/tmp/zz/openstack/latest# cat meta_data.json
{"files": [{"path": "/etc/injected_files", "content_path": "/content/"},
{"path": "/etc/trove/conf.d/guest_info.conf", "content_path": "/content/0001"},
{"path": "/etc/trove/conf.d/trove-guestagent.conf", "content_path":
"/content/0002"}], "admin_pass": "pf2ng7tT8JSt", "random_seed":
"uSNqQ3udiKspue4y8R8b4gg33Qe6klYYJa8ebvDS0t4i88rq2Owu4yC8TysAfsmsYpno0rbWpWisiTQ3raAOPsx+kGgkrunM9UR5khs/1XRh60tlpKJVIHZnKpLv4PcisLKL2DDoHaaFLV9lPcVtZi3iTqKu6RhcwFyhh+A0mD0xg2G89qACD/RNhWiAuQs4X8le+qgIeoRb3wwg7+4
[Yahoo-eng-team] [Bug 1592505] Re: stack trace on reboot with NoCloud datasource on reboot
** Changed in: cloud-init Status: Fix Committed => Fix Released -- 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/1592505 Title: stack trace on reboot with NoCloud datasource on reboot Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: initially found when recreating bug 1591181. But the NoCloud datasource will stacktrace on reboot, with something like: failed stage init-local#012Traceback (most recent call last): File "/usr/bin/cloud-init", line 536, in status_wrapper ret = functor(name, args) File "/usr/bin/cloud-init", line 250, in main_init init.fetch(existing=existing) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 357, in fetch return self._get_data_source(existing=existing) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 252, in _get_data_source ds, desc = self._restore_from_checked_cache(existing) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 238, in _restore_from_checked_cache ds.check_instance_id(self.cfg)): File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceNoCloud.py", line 197, in check_instance_id quick_id = _quick_read_instance_id(cmdline_id=self.cmdline_id, AttributeError: 'DataSourceNoCloud' object has no attribute ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: cloud-init 0.7.7~bzr1227-0ubuntu1 [modified: usr/lib/python3/dist-packages/cloudinit/sources/DataSourceNoCloud.py] ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10 Uname: Linux 4.4.0-24-generic x86_64 ApportVersion: 2.20.1-0ubuntu4 Architecture: amd64 Date: Tue Jun 14 17:58:25 2016 PackageArchitecture: all ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1592505/+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 1540844] Re: ML2's assumptions about transactions should be explicit
Reviewed: https://review.openstack.org/275110 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b25f6448d530b51eea4a36b3d087515e8495f53f Submitter: Jenkins Branch:master commit b25f6448d530b51eea4a36b3d087515e8495f53f Author: Kevin Benton Date: Thu May 12 09:17:56 2016 -0700 Ensure ML2's create/update_port methods not in transaction This adds a check to the ML2 create and update port methods which are called by other services to manipulate ports. This check prevents them from passing in a context that is already part of an ongoing DB session because we do not want DB rollbacks to be allowed after the ML2 plugin calls postcommit methods on drivers. This also adds a temporary hack to set an attribute on the context to skip this check to accomadate two L3 code-paths and a subnet code-path that have port manipulations entangled in transactions. This attribute will ultimately be removed once these paths are refactored. Closes-Bug: #1540844 Change-Id: I5aa099c2264636336ab0b76c0826b506e2dc44b6 ** Changed in: neutron 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/1540844 Title: ML2's assumptions about transactions should be explicit Status in neutron: Fix Released Bug description: The create/update/delete of the core resource in ML2 all assume that they will not be called inside of a transaction because they notify drivers with a postcommit call before returning. Calling ML2 with a session already in a transaction leads to unexpected behavior (e.g. no notifications to driver on a rollback) so we should enforce this assumption in code. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540844/+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 1611750] [NEW] LBaaSv2 SELECT FOR UPDATE error in postgresql
Public bug reported:
When deleting or updating a lbaasv2 (creating a listener) in postgresql,
this error happens:
2016-07-26 07:20:42.611 15316 ERROR neutron.api.v2.resource DBError:
(psycopg2.NotSupportedError) FOR UPDATE cannot be applied to the nullable side
of an outer join
2016-07-26 07:20:42.611 15316 ERROR neutron.api.v2.resource [SQL: 'SELECT
lbaas_loadbalancers.tenant_id AS lbaas_loadbalancers_tenant_id,
lbaas_loadbalancers.id AS lbaas_loadbalancers_id, lbaas_loadbalancers.name AS
lbaas_loadbalancers_name, lbaas_loadbalancers.description AS
lbaas_loadbalancers_description, lbaas_loadbalancers.vip_subnet_id AS
lbaas_loadbalancers_vip_subnet_id, lbaas_loadbalancers.vip_port_id AS
lbaas_loadbalancers_vip_port_id, lbaas_loadbalancers.vip_address AS
lbaas_loadbalancers_vip_address, lbaas_loadbalancers.provisioning_status AS
lbaas_loadbalancers_provisioning_status, lbaas_loadbalancers.operating_status
AS lbaas_loadbalancers_operating_status, lbaas_loadbalancers.admin_state_up AS
lbaas_loadbalancers_admin_state_up,
lbaas_loadbalancer_statistics_1.loadbalancer_id AS
lbaas_loadbalancer_statistics_1_loadbalancer_id,
lbaas_loadbalancer_statistics_1.bytes_in AS
lbaas_loadbalancer_statistics_1_bytes_in,
lbaas_loadbalancer_statistics_1.bytes_out AS lbaas_loadba
lancer_statistics_1_bytes_out,
lbaas_loadbalancer_statistics_1.active_connections AS
lbaas_loadbalancer_statistics_1_active_connections,
lbaas_loadbalancer_statistics_1.total_connections AS
lbaas_loadbalancer_statistics_1_total_connections,
providerresourceassociations_1.provider_name AS
providerresourceassociations_1_provider_name,
providerresourceassociations_1.resource_id AS
providerresourceassociations_1_resource_id \nFROM lbaas_loadbalancers LEFT
OUTER JOIN lbaas_loadbalancer_statistics AS lbaas_loadbalancer_statistics_1 ON
lbaas_loadbalancers.id = lbaas_loadbalancer_statistics_1.loadbalancer_id LEFT
OUTER JOIN providerresourceassociations AS providerresourceassociations_1 ON
lbaas_loadbalancers.id = providerresourceassociations_1.resource_id \nWHERE
lbaas_loadbalancers.id = %(id_1)s FOR UPDATE'] [parameters: {'id_1':
u'7edbcecc-9621-4fb5-a8e8-a2d61037ca07'}]
The reason is explained in this thread:
https://www.postgresql.org/message-id/B15DF97D-188F-
4FD1-99B6-BCEB7E0C3E99%40socialserve.com
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611750
Title:
LBaaSv2 SELECT FOR UPDATE error in postgresql
Status in neutron:
New
Bug description:
When deleting or updating a lbaasv2 (creating a listener) in
postgresql, this error happens:
2016-07-26 07:20:42.611 15316 ERROR neutron.api.v2.resource DBError:
(psycopg2.NotSupportedError) FOR UPDATE cannot be applied to the nullable side
of an outer join
2016-07-26 07:20:42.611 15316 ERROR neutron.api.v2.resource [SQL: 'SELECT
lbaas_loadbalancers.tenant_id AS lbaas_loadbalancers_tenant_id,
lbaas_loadbalancers.id AS lbaas_loadbalancers_id, lbaas_loadbalancers.name AS
lbaas_loadbalancers_name, lbaas_loadbalancers.description AS
lbaas_loadbalancers_description, lbaas_loadbalancers.vip_subnet_id AS
lbaas_loadbalancers_vip_subnet_id, lbaas_loadbalancers.vip_port_id AS
lbaas_loadbalancers_vip_port_id, lbaas_loadbalancers.vip_address AS
lbaas_loadbalancers_vip_address, lbaas_loadbalancers.provisioning_status AS
lbaas_loadbalancers_provisioning_status, lbaas_loadbalancers.operating_status
AS lbaas_loadbalancers_operating_status, lbaas_loadbalancers.admin_state_up AS
lbaas_loadbalancers_admin_state_up,
lbaas_loadbalancer_statistics_1.loadbalancer_id AS
lbaas_loadbalancer_statistics_1_loadbalancer_id,
lbaas_loadbalancer_statistics_1.bytes_in AS
lbaas_loadbalancer_statistics_1_bytes_in,
lbaas_loadbalancer_statistics_1.bytes_out AS lbaas_load
balancer_statistics_1_bytes_out,
lbaas_loadbalancer_statistics_1.active_connections AS
lbaas_loadbalancer_statistics_1_active_connections,
lbaas_loadbalancer_statistics_1.total_connections AS
lbaas_loadbalancer_statistics_1_total_connections,
providerresourceassociations_1.provider_name AS
providerresourceassociations_1_provider_name,
providerresourceassociations_1.resource_id AS
providerresourceassociations_1_resource_id \nFROM lbaas_loadbalancers LEFT
OUTER JOIN lbaas_loadbalancer_statistics AS lbaas_loadbalancer_statistics_1 ON
lbaas_loadbalancers.id = lbaas_loadbalancer_statistics_1.loadbalancer_id LEFT
OUTER JOIN providerresourceassociations AS providerresourceassociations_1 ON
lbaas_loadbalancers.id = providerresourceassociations_1.resource_id \nWHERE
lbaas_loadbalancers.id = %(id_1)s FOR UPDATE'] [parameters: {'id_1':
u'7edbcecc-9621-4fb5-a8e8-a2d61037ca07'}]
The reason is explained in this thread:
https://www.postgresql.org/message-id/B15DF97D-188F-
4FD1-99B6-BCEB7E0C3E99%40socialserve.com
To manage notification
[Yahoo-eng-team] [Bug 1611746] [NEW] rpc callback framework doesn't push context
Public bug reported: The logic to push objects onto the wire to the agents (neutron/api/rpc/handlers/resources_rpc.py) doesn't send the context with it. This makes it difficult to trace a request-ID all of the way through to actions on the agent. It would be nice if we sent the context to preserve the request-ID. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611746 Title: rpc callback framework doesn't push context Status in neutron: New Bug description: The logic to push objects onto the wire to the agents (neutron/api/rpc/handlers/resources_rpc.py) doesn't send the context with it. This makes it difficult to trace a request-ID all of the way through to actions on the agent. It would be nice if we sent the context to preserve the request-ID. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611746/+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 1611681] [NEW] test_db_find_column_type_list failing in gate
Public bug reported:
duplicate tag entry causing failure. example from
http://logs.openstack.org/10/275110/13/check/gate-neutron-dsvm-
functional/8cd2e03/testr_results.html.gz
Traceback (most recent call last):
File "neutron/tests/functional/agent/test_ovs_lib.py", line 395, in
test_db_find_column_type_list
self.assertItemsEqual(tags_present, len_0_list)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 1182, in assertItemsEqual
return self.assertSequenceEqual(expected, actual, msg=msg)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 1014, in assertSequenceEqual
self.fail(msg)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 690, in fail
raise self.failureException(msg)
AssertionError: Sequences differ: [{'tag': 1}, {'tag': 42}, {'tag': 1979}] !=
[{'tag': 1}, {'tag': 42}, {'tag': 1979}, {'tag': 1979}]
Second sequence contains 1 additional elements.
First extra element 3:
{'tag': 1979}
- [{'tag': 1}, {'tag': 42}, {'tag': 1979}]
+ [{'tag': 1}, {'tag': 42}, {'tag': 1979}, {'tag': 1979}]
? +++
** Affects: neutron
Importance: Critical
Status: New
** Tags: gate-failure ovs-lib
** Changed in: neutron
Importance: Undecided => Critical
** Tags added: gate-failure ovs-lib
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611681
Title:
test_db_find_column_type_list failing in gate
Status in neutron:
New
Bug description:
duplicate tag entry causing failure. example from
http://logs.openstack.org/10/275110/13/check/gate-neutron-dsvm-
functional/8cd2e03/testr_results.html.gz
Traceback (most recent call last):
File "neutron/tests/functional/agent/test_ovs_lib.py", line 395, in
test_db_find_column_type_list
self.assertItemsEqual(tags_present, len_0_list)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 1182, in assertItemsEqual
return self.assertSequenceEqual(expected, actual, msg=msg)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 1014, in assertSequenceEqual
self.fail(msg)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 690, in fail
raise self.failureException(msg)
AssertionError: Sequences differ: [{'tag': 1}, {'tag': 42}, {'tag': 1979}] !=
[{'tag': 1}, {'tag': 42}, {'tag': 1979}, {'tag': 1979}]
Second sequence contains 1 additional elements.
First extra element 3:
{'tag': 1979}
- [{'tag': 1}, {'tag': 42}, {'tag': 1979}]
+ [{'tag': 1}, {'tag': 42}, {'tag': 1979}, {'tag': 1979}]
? +++
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1611681/+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 1327061] Re: flavor extras cpu_period out of range will cause unsupported configuration
** Changed in: horizon Status: In Progress => Invalid -- 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/1327061 Title: flavor extras cpu_period out of range will cause unsupported configuration Status in OpenStack Dashboard (Horizon): Invalid Bug description: Flavor extras cpu_period has a range [1000, 100]. Now there is no check about the value. And then if you create an instance using this flavor, it will get a exception: unsupported configuration: Value of cputune period must be in range [1000, 100] To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1327061/+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 1596829] Re: String interpolation should be delayed at logging calls
Reviewed: https://review.openstack.org/352178
Committed:
https://git.openstack.org/cgit/openstack/congress/commit/?id=fb921a86d339a632e21404acb11eed735f9dab62
Submitter: Jenkins
Branch:master
commit fb921a86d339a632e21404acb11eed735f9dab62
Author: Takashi NATSUME
Date: Mon Aug 8 10:01:55 2016 +0900
Fix string interpolation at logging call
Skip creating the formatted log message
if the message is not going to be emitted
because of the log level.
See the oslo i18n guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html#\
adding-variables-to-log-messages
Change-Id: Ie9f3c9179cdae57ee298149f829811a5422fb9aa
Closes-Bug: #1596829
** Changed in: congress
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/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in congress:
Fix Released
Status in Glance:
In Progress
Status in glance_store:
New
Status in heat:
New
Status in Ironic:
Fix Released
Status in masakari:
Fix Released
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
Fix Released
Status in os-vif:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-glanceclient:
Fix Released
Status in python-neutronclient:
Fix Released
Status in OpenStack Object Storage (swift):
New
Status in taskflow:
New
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1607585] Re: neutron server report error when get loadbalance status
Reviewed: https://review.openstack.org/348652 Committed: https://git.openstack.org/cgit/openstack/neutron-lbaas/commit/?id=b09d4d2ee0ea71a52679f0eb2743116dbb7e5442 Submitter: Jenkins Branch:master commit b09d4d2ee0ea71a52679f0eb2743116dbb7e5442 Author: ahdj007 Date: Fri Jul 29 10:38:41 2016 +0800 Delete the "self" when call "_set_degraded" function Which will raise Exception: TypeError: 'LoadBalancerPluginv2' object does not support item assignment. Change-Id: Ic3f653468c7cec8cc0434d3df9b42cc1660f9260 Closes-Bug: #1607585 ** Changed in: neutron 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/1607585 Title: neutron server report error when get loadbalance status Status in neutron: Fix Released Bug description: 2014-01-29 06:43:31.602 11340 ERROR neutron.api.v2.resource [req-d7fb09f3-f5b0-433f-8142-70c2515b78bc ] statuses failed 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource Traceback (most recent call last): 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource File "/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 83, in resource 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource result = method(request=request, **args) 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource File "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 207, in _handle_action 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource return getattr(self._plugin, name)(*arg_list, **kwargs) 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource File "/usr/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py", line 1010, in statuses 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource self._set_degraded(self, listener_status, lb_status) 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource File "/usr/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py", line 1044, in _set_degraded 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource obj["operating_status"] = lb_const.DEGRADED 2014-01-29 06:43:31.602 11340 TRACE neutron.api.v2.resource TypeError: 'LoadBalancerPluginv2' object does not support item assignment To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1607585/+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 1555666] Re: Nova FC and iSCSI volume drivers use same 'iscsi_use_multipath' conf entry for multipath
*** This bug is a duplicate of bug 1593860 *** https://bugs.launchpad.net/bugs/1593860 ** This bug has been marked a duplicate of bug 1593860 iscsi_use_multipath confusing -- 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/1555666 Title: Nova FC and iSCSI volume drivers use same 'iscsi_use_multipath' conf entry for multipath Status in OpenStack Compute (nova): In Progress Bug description: Version: commit f4dd117a81c68d9fb600dff456e1171841758b43 Merge: 09fc0af 52ea564 Author: Jenkins Date: Thu Mar 10 12:35:11 2016 + Merge "Use generic wrapper for cinder exceptions" Issue: Both FC & iSCSI drivers decide on multipath based on the 'iscsi_use_multipath' config parameter. This is ambiguous and we need to have different conf entries for iSCSI and FC, which will enable user to selectively use a feature Code Block: - FC: class LibvirtFibreChannelVolumeDriver(libvirt_volume.LibvirtBaseVolumeDriver): """Driver to attach Fibre Channel Network volumes to libvirt.""" def __init__(self, connection): super(LibvirtFibreChannelVolumeDriver, self).__init__(connection, is_block_dev=False) # Call the factory here so we can support # more than x86 architectures. self.connector = connector.InitiatorConnector.factory( 'FIBRE_CHANNEL', utils.get_root_helper(), use_multipath=CONF.libvirt.iscsi_use_multipath, device_scan_attempts=CONF.libvirt.num_iscsi_scan_tries) iSCSI: class LibvirtISCSIVolumeDriver(libvirt_volume.LibvirtBaseVolumeDriver): """Driver to attach Network volumes to libvirt.""" def __init__(self, connection): super(LibvirtISCSIVolumeDriver, self).__init__(connection, is_block_dev=True) # Call the factory here so we can support # more than x86 architectures. self.connector = connector.InitiatorConnector.factory( 'ISCSI', utils.get_root_helper(), use_multipath=CONF.libvirt.iscsi_use_multipath, device_scan_attempts=CONF.libvirt.num_iscsi_scan_tries, transport=self._get_transport()) LibvirtDriver: def get_volume_connector(self, instance): root_helper = utils.get_root_helper() return connector.get_connector_properties( root_helper, CONF.my_block_storage_ip, CONF.libvirt.iscsi_use_multipath, enforce_multipath=True, host=CONF.host) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1555666/+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 1611632] [NEW] neutron_dynamic_routing project is bound to rpc driver closely
Public bug reported: The interface https://github.com/openstack/neutron-dynamic- routing/blob/master/neutron_dynamic_routing/services/bgp/bgp_plugin.py is bound to rpc driver so closely, it is not suitable to extend the BGP driver which is agentless. So we need to do following steps: 1> Refactor the code to support agentless driver 2> Using service_providers method to load the different driver 3> Deliver an overall agent driver interface so that some agent driver such as quagga and ryu are easy to be load. ** Affects: neutron Importance: Undecided Assignee: Yang Yu (yuyangbj) Status: New ** Tags: l3-bgp ** Changed in: neutron Assignee: (unassigned) => Yang Yu (yuyangbj) ** Tags added: l3-bgp -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611632 Title: neutron_dynamic_routing project is bound to rpc driver closely Status in neutron: New Bug description: The interface https://github.com/openstack/neutron-dynamic- routing/blob/master/neutron_dynamic_routing/services/bgp/bgp_plugin.py is bound to rpc driver so closely, it is not suitable to extend the BGP driver which is agentless. So we need to do following steps: 1> Refactor the code to support agentless driver 2> Using service_providers method to load the different driver 3> Deliver an overall agent driver interface so that some agent driver such as quagga and ryu are easy to be load. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611632/+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
