[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: swauth Importance: Undecided Status: New ** Changed in: swauth Assignee: (unassigned) => abdul nizamuddin (abdul-nizamuddin) ** Changed in: swauth Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in Swift Authentication: In Progress Status in OpenStack Object Storage (swift): In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633343] [NEW] agent/linux/utils.py: string match will fail in the i18n situation
Public bug reported: In function execute(), exception RuntimeError may be raised. The users of execute() may match the return code or other message, but this will be wrong in i18n. ** Affects: neutron Importance: Undecided Assignee: Duan Jiong (duanjiong) Status: New ** Tags: utils ** Changed in: neutron Assignee: (unassigned) => Duan Jiong (duanjiong) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633343 Title: agent/linux/utils.py: string match will fail in the i18n situation Status in neutron: New Bug description: In function execute(), exception RuntimeError may be raised. The users of execute() may match the return code or other message, but this will be wrong in i18n. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633343/+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 1629227] Re: Floating-ip-creation
** Changed in: neutron Status: Opinion => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629227 Title: Floating-ip-creation Status in neutron: Incomplete Bug description: On network node a floating ip is being created by assigning a range of floating ip address to external network pool on routers, where gateway addresses and dhcp is disabled, but here neutronclient/v2_0/client.py returns an empty list to ceilometer which is wrong it should return a floating ip status or something meaningful. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1629227/+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 1633339] [NEW] test_routers_flavors is assuming the reference l3 plugin
Public bug reported: test_routers_flavors is assuming the reference l3 plugin. specifically it assumes specific service profile drivers. ** Affects: neutron Importance: Undecided Assignee: YAMAMOTO Takashi (yamamoto) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/169 Title: test_routers_flavors is assuming the reference l3 plugin Status in neutron: In Progress Bug description: test_routers_flavors is assuming the reference l3 plugin. specifically it assumes specific service profile drivers. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/169/+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 1633337] [NEW] There is no event send out when floating updated
Public bug reported: We register the event with this constant https://github.com/openstack/neutron/blob/master/neutron/callbacks/resources.py#L16, It is the string 'floating_ip'. But from the log message "Notify callbacks [] for floatingip, before_response", the resource name is 'floatingip'. There is no '_'. Due to this different name for the resource, there is no event send out when floating ip updated. ** Affects: neutron Importance: Undecided Assignee: Alex Xu (xuhj) Status: New ** Changed in: neutron Assignee: (unassigned) => Alex Xu (xuhj) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/167 Title: There is no event send out when floating updated Status in neutron: New Bug description: We register the event with this constant https://github.com/openstack/neutron/blob/master/neutron/callbacks/resources.py#L16, It is the string 'floating_ip'. But from the log message "Notify callbacks [] for floatingip, before_response", the resource name is 'floatingip'. There is no '_'. Due to this different name for the resource, there is no event send out when floating ip updated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/167/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
Fix proposed to branch: master Review: https://review.openstack.org/386386 ** Changed in: searchlight Status: New => In Progress ** Changed in: gce-api 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in OpenStack Object Storage (swift): New Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) => iswarya vakati (v-iswarya) ** Also affects: swift Importance: Undecided Status: New ** Changed in: swift Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Confirmed Status in Karbor: New Status in OpenStack Identity (keystone): New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in OpenStack Object Storage (swift): New Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633323] [NEW] [available-zone]az cachee in process make mistake
Public bug reported: Description === when getting in instance's detail info, AZ info is wrong Steps to reproduce == 1. in nova.conf, set memcached_servers = None 2.current az info: nova aggregate-list Id name Availability Zone 1 cas1-agg cas1 modifiy az info: nova aggregate-update 1 cas1-agg cas2 3.get instance az info: nova show ID Expected result === AZ info is cas2 Actual result = AZ info is not stable.sometimes AZ is cas1, sometimes is cas2 Reason === nova-api is multi-processing. When setting memcache server to none, nova-api will cache az in process memory. But nova-api processes caches are not consistent. So I suggest nova-api does not cache az info in process memory. Related file is nova/openstack/common/memorycached.py Related class is Client. ** Affects: nova Importance: Undecided Assignee: xhzhf (guoyongxhzhf) Status: New ** Changed in: nova Assignee: (unassigned) => xhzhf (guoyongxhzhf) -- 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/1633323 Title: [available-zone]az cachee in process make mistake Status in OpenStack Compute (nova): New Bug description: Description === when getting in instance's detail info, AZ info is wrong Steps to reproduce == 1. in nova.conf, set memcached_servers = None 2.current az info: nova aggregate-list Id name Availability Zone 1 cas1-agg cas1 modifiy az info: nova aggregate-update 1 cas1-agg cas2 3.get instance az info: nova show ID Expected result === AZ info is cas2 Actual result = AZ info is not stable.sometimes AZ is cas1, sometimes is cas2 Reason === nova-api is multi-processing. When setting memcache server to none, nova-api will cache az in process memory. But nova-api processes caches are not consistent. So I suggest nova-api does not cache az info in process memory. Related file is nova/openstack/common/memorycached.py Related class is Client. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633323/+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 1629227] Re: Floating-ip-creation
** Changed in: neutron Status: Incomplete => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629227 Title: Floating-ip-creation Status in neutron: Opinion Bug description: On network node a floating ip is being created by assigning a range of floating ip address to external network pool on routers, where gateway addresses and dhcp is disabled, but here neutronclient/v2_0/client.py returns an empty list to ceilometer which is wrong it should return a floating ip status or something meaningful. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1629227/+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 1633288] Re: Projects table extra Enabled column
Reviewed: https://review.openstack.org/383885 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=e483dd047b0466abba13371a6730c2b2ad463354 Submitter: Jenkins Branch:master commit e483dd047b0466abba13371a6730c2b2ad463354 Author: Cindy Lu Date: Fri Oct 7 13:32:35 2016 -0700 Project table has an extra Enabled column definition There are two Enabled column definitions, remove the one attached to v3 enabled (unrelated to v3 too). Closes-Bug: #1633288 Change-Id: I8ba74eba843b72ba1d55c5237d2972c45057afb7 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1633288 Title: Projects table extra Enabled column Status in OpenStack Dashboard (Horizon): Fix Released Bug description: There are two Enabled column definitions, remove the one attached to v3 enabled (unrelated to v3 too). Remove. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1633288/+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 1633306] [NEW] Partial HA network causing HA router creation failed (race conditon)
Public bug reported: ENV: stable/mitaka,VXLAN Neutron API: two neutron-servers behind a HA proxy VIP. Exception log: [1] http://paste.openstack.org/show/585669/ [2] http://paste.openstack.org/show/585670/ Log [1] shows that the subnet of HA network is concurrently deleted while a new HA router create API comes. Seems the race conditon described in this bug is till exists : https://bugs.launchpad.net/neutron/+bug/1533440 Log [2] has a very strange behavior that those 3 API has a same request- id [req-780b1f6e-2b3c-4303-a1de-a5fb4c7ea31e]. Test scenario: Just create one HA router for a tenant, and then quickly delete it. For now, our mitaka ENV use VxLAN as tenant network type. So there is a very large range of VNI. So don't save that, and temporarily solution, we add a new config to decide whether delete the HA network every time. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633306 Title: Partial HA network causing HA router creation failed (race conditon) Status in neutron: New Bug description: ENV: stable/mitaka,VXLAN Neutron API: two neutron-servers behind a HA proxy VIP. Exception log: [1] http://paste.openstack.org/show/585669/ [2] http://paste.openstack.org/show/585670/ Log [1] shows that the subnet of HA network is concurrently deleted while a new HA router create API comes. Seems the race conditon described in this bug is till exists : https://bugs.launchpad.net/neutron/+bug/1533440 Log [2] has a very strange behavior that those 3 API has a same request-id [req-780b1f6e-2b3c-4303-a1de-a5fb4c7ea31e]. Test scenario: Just create one HA router for a tenant, and then quickly delete it. For now, our mitaka ENV use VxLAN as tenant network type. So there is a very large range of VNI. So don't save that, and temporarily solution, we add a new config to decide whether delete the HA network every time. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633306/+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 1633296] [NEW] Pecan tempest API test jobs timeout
Public bug reported: Looks like its because of a ton of dhcp notifications being sent out. The problem being that pecan tries to grab the plugins dhcp notifier, but fails, so it instantiates its own. This happens for every request, and when the dhcp notifier is instantiated it subscribes to notifications. This means, with pecan instantiating a new dhcp notifier for every request, the subscriptions keep growing and growing. ** Affects: neutron Importance: High Assignee: Brandon Logan (brandon-logan) Status: Confirmed ** Tags: api ** Changed in: neutron Status: New => Confirmed ** Changed in: neutron Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633296 Title: Pecan tempest API test jobs timeout Status in neutron: Confirmed Bug description: Looks like its because of a ton of dhcp notifications being sent out. The problem being that pecan tries to grab the plugins dhcp notifier, but fails, so it instantiates its own. This happens for every request, and when the dhcp notifier is instantiated it subscribes to notifications. This means, with pecan instantiating a new dhcp notifier for every request, the subscriptions keep growing and growing. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633296/+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 1633293] [NEW] Deprecation warning when service_providers empty
Public bug reported: When fetching the service_providers the code looks like [1]. So if the cfg.CONF.service_providers.service_provider field is empty we will always get a deprecation warning even if there is nothing actually configured in the neutron_*.conf files. In the event that you have CONF.fatal_deprecations on this halts the program. I'm still going through to see what this value should be, but even if it's an empty list it shouldn't fail with an incorrect deprecation warning. [1] https://github.com/openstack/neutron/blob/1628fb72f8fbac15110713530728a03e8e4bd0f5/neutron/services/provider_configuration.py#L112-L122 ** Affects: neutron Importance: Undecided Assignee: Jamie Lennox (jamielennox) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633293 Title: Deprecation warning when service_providers empty Status in neutron: In Progress Bug description: When fetching the service_providers the code looks like [1]. So if the cfg.CONF.service_providers.service_provider field is empty we will always get a deprecation warning even if there is nothing actually configured in the neutron_*.conf files. In the event that you have CONF.fatal_deprecations on this halts the program. I'm still going through to see what this value should be, but even if it's an empty list it shouldn't fail with an incorrect deprecation warning. [1] https://github.com/openstack/neutron/blob/1628fb72f8fbac15110713530728a03e8e4bd0f5/neutron/services/provider_configuration.py#L112-L122 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633293/+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 1632633] Re: fix some word spelling error
** Changed in: neutron Status: Fix Committed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1632633 Title: fix some word spelling error Status in neutron: Invalid Bug description: there are some word spelling error in .py file. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1632633/+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 1633288] [NEW] Projects table extra Enabled column
Public bug reported: There are two Enabled column definitions, remove the one attached to v3 enabled (unrelated to v3 too). Remove. ** Affects: horizon Importance: Low Assignee: Cindy Lu (clu-m) Status: In Progress ** Tags: newton-backport-potential -- 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/1633288 Title: Projects table extra Enabled column Status in OpenStack Dashboard (Horizon): In Progress Bug description: There are two Enabled column definitions, remove the one attached to v3 enabled (unrelated to v3 too). Remove. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1633288/+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 1632633] Re: fix some word spelling error
** Changed in: neutron Status: Invalid => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1632633 Title: fix some word spelling error Status in neutron: Fix Committed Bug description: there are some word spelling error in .py file. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1632633/+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 1632633] Re: fix some word spelling error
** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1632633 Title: fix some word spelling error Status in neutron: Fix Committed Bug description: there are some word spelling error in .py file. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1632633/+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 1632633] Re: fix some word spelling error
** Changed in: neutron Status: Invalid => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1632633 Title: fix some word spelling error Status in neutron: Fix Committed Bug description: there are some word spelling error in .py file. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1632633/+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 1633280] [NEW] need a way to disable anti-spoofing rules and yet keep security groups
Public bug reported: Basically all NFV use-cases would require this split. The current approach for NFV is to turn things off and have the VNFs protect themselves rather than the infra-structure supports security. Even in simple deployments, like cloud bursting, you'll need to be able to allow the customer to control his addressing. The customer might want to do so by having the router (which does the IPSEC tunnel termination) either use ICMP RA (in case of v6/SLAAC) or DHCP (v4/v6) to control addressing - as opposed to have openstack control the addressing. In this case, the VNF only deals with addressing but it has to protect itself without security groups. ** Affects: neutron Importance: Undecided Assignee: Rui Zang (rui-zang) Status: New ** Changed in: neutron Assignee: (unassigned) => Rui Zang (rui-zang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633280 Title: need a way to disable anti-spoofing rules and yet keep security groups Status in neutron: New Bug description: Basically all NFV use-cases would require this split. The current approach for NFV is to turn things off and have the VNFs protect themselves rather than the infra-structure supports security. Even in simple deployments, like cloud bursting, you'll need to be able to allow the customer to control his addressing. The customer might want to do so by having the router (which does the IPSEC tunnel termination) either use ICMP RA (in case of v6/SLAAC) or DHCP (v4/v6) to control addressing - as opposed to have openstack control the addressing. In this case, the VNF only deals with addressing but it has to protect itself without security groups. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633280/+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 1633218] Re: OS_INTERFACE from openrc breaks keystone
Reviewed: https://review.openstack.org/386238 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=276eaf32e22070cb9ab38dc09b84d5c30ebd9138 Submitter: Jenkins Branch:master commit 276eaf32e22070cb9ab38dc09b84d5c30ebd9138 Author: David Medberry Date: Thu Oct 13 15:24:30 2016 -0600 OS_INTERFACE was errantly added to the V2 openrc Change-Id: Id87af991f4efe78efa955c6b71d5fe19dccdb165 Closes-Bug: #1633218 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1633218 Title: OS_INTERFACE from openrc breaks keystone Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When doing a "openstack project list" after sourcing the openrc file returned in Horizon, many keystone results break (and or are truncated.) Unsetting "OS_INTERFACE" restores the proper behavior. Tested with latest pip of python-openstackclient and python- keystoneclient To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1633218/+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 1633249] [NEW] Boot volume creation leaves secondary volume attached to broken server
Public bug reported: Attempt to boot a server with a block device mapping that includes a boot volume created from an image, plus an existing data volume. If the boot-volume creation fails, the data volume is left in state "in-use", attached to the server which is now in "error" state". The user can't detach the volume because of the server's error state. They can delete the server, which then leaves the volume apparently attached to a server that no longer exists. The only way out of this is to ask an administrator to reset the state of the data volume (this option is not available to regular users by default policy). The easiest way to reproduce this is to attempt to create the boot volume from qcow2 image where the volume size is less than the image (virtual) size. ~$ cinder list +--+---+--+--+-+--+-+ | ID | Status| Name | Size | Volume Type | Bootable | Attached to | +--+---+--+--+-+--+-+ | 2e733722-8b19-4bff-bd8d-bb770554582a | available | data | 1| - | false| | +--+---+--+--+-+--+-+ ~$ nova boot --flavor m1.large --availability-zone=imot04-1 --block-device 'id=9e122d18-d7a4-406d-b8f2-446cfddaa7c7,source=image,dest=volume,device=vda,size=5,bootindex=0' --block-device 'id=2e733722-8b19-4bff-bd8d-bb770554582a,source=volume,dest=volume,device=vdb,size=1,bootindex=1' ol4 +--+--+ | Property | Value | +--+--+ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | imot04-1 | | OS-EXT-SRV-ATTR:host | - | | OS-EXT-SRV-ATTR:hypervisor_hostname | - | | OS-EXT-SRV-ATTR:instance_name| | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state| scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass| DNTr8MG3kVmC | | config_drive | | | created | 2016-10-13T21:54:08Z | | flavor | m1.large (4) | | hostId | | | id | 9541b63c-e003-4bcc-bcb8-5c0461522387 | | image| Attempt to boot from volume - no image supplied | | key_name | - | | metadata | {} | | name | ol4 | | os-extended-volumes:volumes_attached | [{"id": "2e733722-8b19-4bff-bd8d-bb770554582a"}] | | progress | 0 | | security_groups | default | | status | BUILD | | tenant_id| 66234fea2ccc42398a1ae5300c594d49 | | updated | 2016-10-13T21:54:08Z | | user_id | b2ae6b7bdac142ddb708a3550f61d998 | +--+--+ ~$ cinder list +--+--+--+--+-+--+--+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +---
[Yahoo-eng-team] [Bug 1633236] [NEW] If volume detach fails, it cannot be retried and the instance must be rebooted to detach
Public bug reported: There is a problem where if a volume detach fails at the libvirt driver level for some reason, the volume detach cannot be retried and the volume cannot be detached until the instance is rebooted. Currently, a volume detach at the libvirt driver level happens in two steps: 1. Detach from the persistent domain (this will affect the instance upon next reboot) 2. Detach from the transient domain (this will affect the running instance) A detach from a transient domain is a request from the host to the guest, to detach the volume. The guest can choose to ignore this request. For example, if the guest has a file open on the volume by some process, it might ignore the request to detach that volume because it is busy. If this scenario occurs, when a user tries a later request to detach the volume, it will fail with the error: libvirtError: invalid argument: no target device because the volume was detached from the persistent domain the first time. Because of this, the volume can only be detached by rebooting the instance. The behavior should be changed to detach from the transient domain first, retrying if necessary, and detach from the persistent domain only if the detach from the transient domain has succeeded. This way, if the guest volume is busy and it ignores the detach request, the detach can be tried again at a later time by the user. Suggested steps to reproduce: 1. Boot an instance and attach a volume 2. Log in to the guest and open a file on that volume in a text editor 3. Try to detach the volume using 'nova volume-detach' (it should have failed) 4. Exit the text editor on the guest 5. Try to detach the volume using 'nova volume-detach' (should get the 'no target device' error) ** Affects: nova Importance: Undecided Assignee: melanie witt (melwitt) Status: In Progress ** Tags: libvirt -- 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/1633236 Title: If volume detach fails, it cannot be retried and the instance must be rebooted to detach Status in OpenStack Compute (nova): In Progress Bug description: There is a problem where if a volume detach fails at the libvirt driver level for some reason, the volume detach cannot be retried and the volume cannot be detached until the instance is rebooted. Currently, a volume detach at the libvirt driver level happens in two steps: 1. Detach from the persistent domain (this will affect the instance upon next reboot) 2. Detach from the transient domain (this will affect the running instance) A detach from a transient domain is a request from the host to the guest, to detach the volume. The guest can choose to ignore this request. For example, if the guest has a file open on the volume by some process, it might ignore the request to detach that volume because it is busy. If this scenario occurs, when a user tries a later request to detach the volume, it will fail with the error: libvirtError: invalid argument: no target device because the volume was detached from the persistent domain the first time. Because of this, the volume can only be detached by rebooting the instance. The behavior should be changed to detach from the transient domain first, retrying if necessary, and detach from the persistent domain only if the detach from the transient domain has succeeded. This way, if the guest volume is busy and it ignores the detach request, the detach can be tried again at a later time by the user. Suggested steps to reproduce: 1. Boot an instance and attach a volume 2. Log in to the guest and open a file on that volume in a text editor 3. Try to detach the volume using 'nova volume-detach' (it should have failed) 4. Exit the text editor on the guest 5. Try to detach the volume using 'nova volume-detach' (should get the 'no target device' error) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633236/+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 1619423] Re: snappy does not include ssh-import-id preventing cloud-init user-data from importing ssh-keys
** Also affects: cloud-init Importance: Undecided Status: New -- 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/1619423 Title: snappy does not include ssh-import-id preventing cloud-init user-data from importing ssh-keys Status in cloud-init: New Status in Snappy: Confirmed Bug description: cloud-init user-data can specify adding users with users: - name: linda ssh-import-keys: linda.user and after user account creation, cloud-init invokes: sudo -Hu linda ssh-import-id linda-user This fails as ssh-import-id isn't part of the Ubuntu-Core image To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1619423/+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 1633218] [NEW] OS_INTERFACE from openrc breaks keystone
Public bug reported: When doing a "openstack project list" after sourcing the openrc file returned in Horizon, many keystone results break (and or are truncated.) Unsetting "OS_INTERFACE" restores the proper behavior. Tested with latest pip of python-openstackclient and python- keystoneclient ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1633218 Title: OS_INTERFACE from openrc breaks keystone Status in OpenStack Dashboard (Horizon): New Bug description: When doing a "openstack project list" after sourcing the openrc file returned in Horizon, many keystone results break (and or are truncated.) Unsetting "OS_INTERFACE" restores the proper behavior. Tested with latest pip of python-openstackclient and python- keystoneclient To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1633218/+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 1633200] Re: Unable to create server with image that has hw_watchdog_action='disabled'
** No longer affects: nova/newton -- 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/1633200 Title: Unable to create server with image that has hw_watchdog_action='disabled' Status in OpenStack Compute (nova): In Progress Bug description: This is from ocata devstack. Set the hw_watchdog_action image property with value 'disabled': stack@osc:~$ openstack image set --property hw_watchdog_action=disabled cirros-0.3.4-x86_64-uec stack@osc:~$ openstack image show -c properties cirros-0.3.4-x86_64-uec +++ | Field | Value | +++ | properties | hw_watchdog_action='disabled', kernel_id='08463073-3460-4b5f-92cc-ade974936e96', ramdisk_id='ff195fc4-c039-43b5-acca-501aba68aba2' | +++ Then try to boot the server and it will fail: stack@osc:~$ nova boot --poll --image c8af19ff-cebc-4112-a237-78dcd19e588c --flavor 42 test-watchdog-disabled ERROR (BadRequest): Invalid image metadata. Error: Field value disabled is invalid (HTTP 400) (Request-ID: req-488be9ab-ebcb-473b-b238-968f91ed0f48) stack@osc:/opt/stack/nova$ git log -1 commit 7a9eb10d0d15e5327aa73c72418d89afce11abef Merge: b796673 951dee3 Author: Jenkins Date: Wed Oct 5 18:27:22 2016 + Merge "Fix periodic-nova-py{27,35}-with-oslo-master" The problem is the ImageMetaProps object in nova is using enums for the hw_watchdog_action field: https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/objects/fields.py#L383 And that doesn't have 'disabled' as a value. However, if you look at the glance metadef it's an option, so someone using Horizon could set this: https://github.com/openstack/glance/blob/d3e820724e1d578003b13e72e753d9b1d75173e1/etc/metadefs /compute-watchdog.json#L25 And the libvirt driver actually defaults to 'disabled': https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/virt/libvirt/driver.py#L4536 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633200/+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 1631517] Re: No formal statement of project name restrictions
Reviewed: https://review.openstack.org/385241 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1974f2d5dc1e24d1c67258c48f2a5da0dd846cd1 Submitter: Jenkins Branch:master commit 1974f2d5dc1e24d1c67258c48f2a5da0dd846cd1 Author: Steve Martinelli Date: Tue Oct 11 22:46:10 2016 -0400 [api] add a note about project name restrictions Mention that project names are limited to domain, 64 characters, and utf8 support depends on the given backend. Change-Id: Idc266d693c9e81d2bc9b51f20ad5f1282bda5721 Closes-Bug: 1631517 ** 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/1631517 Title: No formal statement of project name restrictions Status in OpenStack Identity (keystone): Fix Released Bug description: I am unable to find any official documentation on project name restrictions. The only two that can be found are 1. It must be uniqe within the domain and 2. No more than 64 characters. http://developer.openstack.org/api-ref/identity/v3/?expanded=create-project-detail only states: "name: The name of the project, which must be unique within the owning domain. A project can have the same name as its domain." https://github.com/openstack/tempest/blob/master/tempest/api/identity/admin/v3/test_projects_negative.py#L60-L64 shows there is a 64 character limit. The name must be sent in a valid json which could be any utf-8 character, but does that always work within limits of all backends that use MySQL. MySQL's restrictions state utf-8, but "can contain only characters in the Basic Multilingual Plane (BMP). Supplementary characters are not permitted in identifiers." https://dev.mysql.com/doc/refman/5.5/en/charset-restrictions.html Please add documentation for restrictions on project names beyond uniqueness and character count. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1631517/+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 1633200] [NEW] Unable to create server with image that has hw_watchdog_action='disabled'
Public bug reported: This is from ocata devstack. Set the hw_watchdog_action image property with value 'disabled': stack@osc:~$ openstack image set --property hw_watchdog_action=disabled cirros-0.3.4-x86_64-uec stack@osc:~$ openstack image show -c properties cirros-0.3.4-x86_64-uec +++ | Field | Value | +++ | properties | hw_watchdog_action='disabled', kernel_id='08463073-3460-4b5f-92cc-ade974936e96', ramdisk_id='ff195fc4-c039-43b5-acca-501aba68aba2' | +++ Then try to boot the server and it will fail: stack@osc:~$ nova boot --poll --image c8af19ff-cebc-4112-a237-78dcd19e588c --flavor 42 test-watchdog-disabled ERROR (BadRequest): Invalid image metadata. Error: Field value disabled is invalid (HTTP 400) (Request-ID: req-488be9ab-ebcb-473b-b238-968f91ed0f48) stack@osc:/opt/stack/nova$ git log -1 commit 7a9eb10d0d15e5327aa73c72418d89afce11abef Merge: b796673 951dee3 Author: Jenkins Date: Wed Oct 5 18:27:22 2016 + Merge "Fix periodic-nova-py{27,35}-with-oslo-master" The problem is the ImageMetaProps object in nova is using enums for the hw_watchdog_action field: https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/objects/fields.py#L383 And that doesn't have 'disabled' as a value. However, if you look at the glance metadef it's an option, so someone using Horizon could set this: https://github.com/openstack/glance/blob/d3e820724e1d578003b13e72e753d9b1d75173e1/etc/metadefs /compute-watchdog.json#L25 And the libvirt driver actually defaults to 'disabled': https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/virt/libvirt/driver.py#L4536 ** Affects: nova Importance: Medium Assignee: Matt Riedemann (mriedem) Status: In Progress ** Affects: nova/newton Importance: Medium Status: Triaged ** Changed in: nova Status: New => In Progress ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova Assignee: (unassigned) => Matt Riedemann (mriedem) ** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Status: New => Confirmed ** Changed in: nova/newton Importance: Undecided => Medium ** Changed in: nova/newton Status: Confirmed => Triaged -- 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/1633200 Title: Unable to create server with image that has hw_watchdog_action='disabled' Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) newton series: Triaged Bug description: This is from ocata devstack. Set the hw_watchdog_action image property with value 'disabled': stack@osc:~$ openstack image set --property hw_watchdog_action=disabled cirros-0.3.4-x86_64-uec stack@osc:~$ openstack image show -c properties cirros-0.3.4-x86_64-uec +++ | Field | Value | +++ | properties | hw_watchdog_action='disabled', kernel_id='08463073-3460-4b5f-92cc-ade974936e96', ramdisk_id='ff195fc4-c039-43b5-acca-501aba68aba2' | +++ Then try to boot the server and it will fail: stack@osc:~$ nova boot --poll --image c8af19ff-cebc-4112-a237-78dcd19e588c --flavor 42 test-watchdog-disabled ERROR (BadRequest): Invalid image metadata. Error: Field value disabled is invalid (HTTP 400) (Request-ID: req-488be9ab-ebcb-473b-b238-968f91ed0f48) stack@osc:/opt/stack/nova$ git log -1 commit 7a9eb10d0d15e5327aa73c72418d89afce11abef Merge: b796673 951dee3 Author: Jenkins Date: Wed Oct 5 18:27:22 2016 + Merge "Fix periodic-nova-py{27,35}-with-oslo-master" The problem is the ImageMetaProps object in nova is using enums for the hw_watchdog_action field: https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c7
[Yahoo-eng-team] [Bug 1627615] Re: Cannot override IDL class in OVSDB connection class
Reviewed: https://review.openstack.org/378391 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=070ee35b9c580904829c6c205163485edd0f4a43 Submitter: Jenkins Branch:master commit 070ee35b9c580904829c6c205163485edd0f4a43 Author: Omer Anson Date: Wed Sep 28 11:17:55 2016 +0300 Allow to override Idl class in OVSDB Connection Add an option to neutron.agent.ovsdb.native.connection.Connection to override the Idl class that is created to communicate with OVSDB. This is a feature that would help in Dragonflow[1], where the notify method should be overriden before start() is called, in order to receive all events in real-time, and not retroactively. [1] https://github.com/openstack/dragonflow/blob/d17ae9705a4f585fe3e87a398823dc983cf985c1/dragonflow/ovsdb/impl_idl.py#L135 Change-Id: I49da05f02a00352b1b1db863d244e97f9c148804 Closes-Bug: 1627615 ** 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/1627615 Title: Cannot override IDL class in OVSDB connection class Status in neutron: Fix Released Bug description: The current ovsdb connection class (neutron.agent.ovsdb.native.connection.Connection) creates an instance of idl.Idl, but does not allow the client of the library to select a different library (e.g. a class overriding idl.Idl). Clients wanting to do this have to re-implement the entire start method, which contains a lot of unrelated logic. This is a feature that would assist us in Dragonflow[1], where we want to override the notify method and get OVSDB events, and have this method overriden at the moment of connection (and not in retrospect). [1]https://github.com/openstack/dragonflow/blob/master/dragonflow/db/drivers/ovsdb_vswitch_impl.py To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1627615/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
Reviewed: https://review.openstack.org/385918 Committed: https://git.openstack.org/cgit/openstack/octavia/commit/?id=9fe5317e004e723d5ad9141cf1e5e90c5f8fe2e5 Submitter: Jenkins Branch:master commit 9fe5317e004e723d5ad9141cf1e5e90c5f8fe2e5 Author: Deepak Date: Thu Oct 13 16:57:37 2016 +0530 Drop MANIFEST.in - it's not needed by pbr octavia already uses PBR:- setuptools.setup( setup_requires=['pbr>=1.8'], pbr=True) This patch removes `MANIFEST.in` file as pbr generates a sensible manifest from git files and some standard files and it removes the need for an explicit `MANIFEST.in` file. Change-Id: I0b6a7a6eb3be8c1982a4fd7576dea1db9890f69c Closes-Bug: #1608980 ** Changed in: octavia 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: Confirmed Status in gce-api: Confirmed Status in Karbor: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: gce-api Importance: Undecided Status: New ** Changed in: gce-api Assignee: (unassigned) => iswarya vakati (v-iswarya) ** Changed in: ec2-api Importance: Undecided => Low ** Changed in: ec2-api Status: New => Confirmed ** Changed in: gce-api Importance: Undecided => Low ** Changed in: gce-api Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: Confirmed Status in gce-api: Confirmed Status in Karbor: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: New Status in Karbor: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1614361] Re: tox.ini needs to be updated as openstack infra now supports upper constraints
Reviewed: https://review.openstack.org/384259 Committed: https://git.openstack.org/cgit/openstack/freezer/commit/?id=ab47e90f217bd9caed7cb35ceabb5a62528bad15 Submitter: Jenkins Branch:master commit ab47e90f217bd9caed7cb35ceabb5a62528bad15 Author: Jeremy Liu Date: Mon Oct 10 10:16:22 2016 +0800 Support upper-constraints in tox.ini Openstack infra now supports upper constraints for all jobs. Update tox.ini to use upper constraints for all jobs. Change-Id: I524b0a31ecf2253bedee52b56109f5ff79b428cb Closes-bug: #1614361 ** Changed in: freezer 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/1614361 Title: tox.ini needs to be updated as openstack infra now supports upper constraints Status in castellan: In Progress Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in Designate: Fix Released Status in Freezer: Fix Released Status in Glance: In Progress Status in heat: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic Inspector: Fix Released Status in Mistral: Fix Released Status in networking-ovn: Invalid Status in octavia: Fix Released Status in python-barbicanclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tacker: Fix Released Status in OpenStack DBaaS (Trove): Invalid Status in vmware-nsx: Fix Released Status in zaqar: Fix Released Status in Zaqar-ui: Fix Released Bug description: Openstack infra now supports upper constraints for releasenotes, cover, venv targets. tox.ini uses install_command for these targets, which can now be safely removed. Reference for mail that details this support: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101474.html To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1614361/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: karbor Importance: Undecided Status: New ** Changed in: karbor Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: New Status in Karbor: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: searchlight Importance: Undecided Status: New ** Changed in: searchlight Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: New Status in Karbor: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1632080] Re: Adding routes to router does not increment its revision number
Reviewed: https://review.openstack.org/384688 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=29e15f9278e8d81fa4d8722deadd8739af60eb51 Submitter: Jenkins Branch:master commit 29e15f9278e8d81fa4d8722deadd8739af60eb51 Author: Omer Anson Date: Mon Oct 10 22:46:32 2016 +0300 Have RouterRoute object increment Router revision When modifying RouterRoute objects on a Router (e.g. adding a route to a router via the ExtraRoute extension), have the modification update the Router's revision number. Change-Id: If9bb56442375efac3043b9de0a03972552ac34bf Closes-Bug: 1632080 ** 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/1632080 Title: Adding routes to router does not increment its revision number Status in neutron: Fix Released Bug description: Adding routes to router does not increment its revision number: As per the following output, note that revision_number is 3 after the call to openstack router set (which succeeded): [stack@l1 ~]$ openstack router show r1 +---+---+ | Field | Value | +---+---+ | admin_state_up| UP| | created_at| 2016-10-10T17:18:45Z | | description | | | external_gateway_info | null | | id| d7400cc1-1ad4-47b4-9a58-f86f0baf7f06 | | name | r1| | project_id| b370e3cd05504661967a04cb119d50ec | | project_id| b370e3cd05504661967a04cb119d50ec | | revision_number | 3 | | routes| destination='10.0.3.0/24', gateway='10.0.1.4' | | status| ACTIVE| | updated_at| 2016-10-10T18:48:31Z | +---+---+ [stack@l1 ~]$ openstack router set --route destination=10.0.4.0/24,gateway=10.0.1.4 r1 [stack@l1 ~]$ openstack router show r1 +---+---+ | Field | Value | +---+---+ | admin_state_up| UP| | created_at| 2016-10-10T17:18:45Z | | description | | | external_gateway_info | null | | id| d7400cc1-1ad4-47b4-9a58-f86f0baf7f06 | | name | r1| | project_id| b370e3cd05504661967a04cb119d50ec | | project_id| b370e3cd05504661967a04cb119d50ec | | revision_number | 3 | | routes| destination='10.0.4.0/24', gateway='10.0.1.4' | | | destination='10.0.3.0/24', gateway='10.0.1.4' | | status| ACTIVE| | updated_at| 2016-10-10T18:48:31Z | +---+---+ Expected output: revision_number is 4 (or more) on the second call to openstack router show r1. Found on commit 355c145 Merge "Cleanup Newton Release Notes" To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1632080/+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 1632742] Re: /v2 route doesn't exist
I must've had this sitting open for a while and completely missed Sean's update. We discussed this at the glance meeting today and decided to agree with Sean's position, namely that a 404 is appropriate. It could make sense to have the versions returned, or it could make sense to have a JSON-home type document returned. So we don't want to be precipitate in deciding what (if anything) to return. ** Changed in: glance Status: Triaged => Won't Fix ** Changed in: glance Assignee: Brian Rosmaita (brian-rosmaita) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1632742 Title: /v2 route doesn't exist Status in Glance: Won't Fix Bug description: Looking at the api-ref docs, I'm able to list versions of the image API available in a cloud (I'm using a devstack created from master as of last week): http://developer.openstack.org/api- ref/image/versions/index.html?expanded=id1-detail#id1 stack@osc:/opt/stack/glance$ git log -1 commit 9bd264cd034f996852372ae0ca988bd67b98cf9a Merge: 2de3caf ce6cb2d Author: Jenkins Date: Tue Oct 4 02:28:10 2016 + Merge "[api-ref] configure LogABug feature" stack@osc:/opt/stack/glance$ I'm able to list versions for the image endpoint: stack@osc:/opt/stack/glance$ curl -s -H "X-Auth-Token: $OS_TOKEN" http://9.5.127.82:9292 | json_pp { "versions" : [ { "id" : "v2.4", "status" : "CURRENT", "links" : [ { "rel" : "self", "href" : "http://9.5.127.82:9292/v2/"; } ] }, { "links" : [ { "rel" : "self", "href" : "http://9.5.127.82:9292/v2/"; } ], "id" : "v2.3", "status" : "SUPPORTED" }, { "links" : [ { "rel" : "self", "href" : "http://9.5.127.82:9292/v2/"; } ], "status" : "SUPPORTED", "id" : "v2.2" }, { "id" : "v2.1", "status" : "SUPPORTED", "links" : [ { "rel" : "self", "href" : "http://9.5.127.82:9292/v2/"; } ] }, { "status" : "SUPPORTED", "id" : "v2.0", "links" : [ { "href" : "http://9.5.127.82:9292/v2/";, "rel" : "self" } ] }, { "links" : [ { "href" : "http://9.5.127.82:9292/v1/";, "rel" : "self" } ], "status" : "DEPRECATED", "id" : "v1.1" }, { "links" : [ { "rel" : "self", "href" : "http://9.5.127.82:9292/v1/"; } ], "id" : "v1.0", "status" : "DEPRECATED" } ] } stack@osc:/opt/stack/glance$ I'm able to list the v1 route which is just a list of images: stack@osc:/opt/stack/glance$ curl -s -H "X-Auth-Token: $OS_TOKEN" http://9.5.127.82:9292/v1/ | json_pp { "images" : [ { "size" : 25165824, "name" : "cirros-0.3.4-x86_64-uec", "id" : "c8af19ff-cebc-4112-a237-78dcd19e588c", "disk_format" : "ami", "checksum" : "eb9139e4942121f22bbc2afc0400b2a4", "container_format" : "ami" }, { "disk_format" : "ari", "container_format" : "ari", "checksum" : "be575a2b939972276ef675752936977f", "size" : 3740163, "name" : "cirros-0.3.4-x86_64-uec-ramdisk", "id" : "ff195fc4-c039-43b5-acca-501aba68aba2" }, { "size" : 4979632, "name" : "cirros-0.3.4-x86_64-uec-kernel", "id" : "08463073-3460-4b5f-92cc-ade974936e96", "disk_format" : "aki", "container_format" : "aki", "checksum" : "8a40c862b5735975d82605c1dd395796" } ] } But I'm not able to list the v2 route: stack@osc:/opt/stack/glance$ curl -s -H "X-Auth-Token: $OS_TOKEN" http://9.5.127.82:9292/v2/ 404 Not Found The resource could not be found. stack@osc:/opt/stack/glance$ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1632742/+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 1633120] [NEW] Nova scheduler tries to assign an already-in-use SRIOV QAT VF to a new instance (openstack-mitaka)
Public bug reported: Upon trying to create VM instance (Say A) with one QAT VF, it fails with the following error i.e., “Requested operation is not valid: PCI device :88:04.7 is in use by driver QEMU, domain instance-0081”. Please note that, PCI device :88:04.7 is already being assigned to another VM (Say B) . We have installed openstack-mitaka release on CentO7 system. It has two Intel QAT devices. There are 32 VF devices available per QAT Device/DH895xCC device Out of 64 VFs, only 8 VFs are allocated (to VM instances) and rest should be available. But the nova scheduler tries to assign an already-in-use SRIOV VF to a new instance and instance fails. It appears that the nova database is not tracking which VF's have already been taken. But if I shut down VM B instance, then other instance VM A boots up and vice-versa. Note that, both the VM instances cannot run simultaneously because of the aforesaid issue. We should always be able to create as many instances with the requested PCI devices as there are available VFs. Please feel free to let me know if additional information is needed. Can anyone please suggest why it tries to assign same PCI device which has been assigned already? Is there any way to resolve this issue? Thank you in advance for your support and help. [root@localhost ~(keystone_admin)]# lspci -d:435 83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT 88:00.0 Co-processor: Intel Corporation DH895XCC Series QAT [root@localhost ~(keystone_admin)]# [root@localhost ~(keystone_admin)]# lspci -d:443 | grep "QAT Virtual Function" | wc -l 64 [root@localhost ~(keystone_admin)]# [root@localhost ~(keystone_admin)]# mysql -u root nova -e "SELECT hypervisor_hostname, address, instance_uuid, status FROM pci_devices JOIN compute_nodes oncompute_nodes.id=compute_node_id" | grep :88:04.7 localhost :88:04.7e10a76f3-e58e-4071-a4dd-7a545e8000deallocated localhost :88:04.7c3dbac90-198d-4150-ba0f-a80b912d8021allocated localhost :88:04.7c7f6adad-83f0-4881-b68f-6d154d565ce3allocated localhost.nfv.benunets.com :88:04.70c3c11a5-f9a4-4f0d-b120-40e4dde843d4 allocated [root@localhost ~(keystone_admin)]# [root@localhost ~(keystone_admin)]# grep -r e10a76f3-e58e-4071-a4dd-7a545e8000de /etc/libvirt/qemu /etc/libvirt/qemu/instance-0081.xml: e10a76f3-e58e-4071-a4dd-7a545e8000de /etc/libvirt/qemu/instance-0081.xml: e10a76f3-e58e-4071-a4dd-7a545e8000de /etc/libvirt/qemu/instance-0081.xml: /etc/libvirt/qemu/instance-0081.xml: /etc/libvirt/qemu/instance-0081.xml: [root@localhost ~(keystone_admin)]# [root@localhost ~(keystone_admin)]# grep -r 0c3c11a5-f9a4-4f0d-b120-40e4dde843d4 /etc/libvirt/qemu /etc/libvirt/qemu/instance-00ab.xml: 0c3c11a5-f9a4-4f0d-b120-40e4dde843d4 /etc/libvirt/qemu/instance-00ab.xml: 0c3c11a5-f9a4-4f0d-b120-40e4dde843d4 /etc/libvirt/qemu/instance-00ab.xml: /etc/libvirt/qemu/instance-00ab.xml: /etc/libvirt/qemu/instance-00ab.xml: [root@localhost ~(keystone_admin)]# On the controller, , it appears there are duplicate PCI device entries in the Database: MariaDB [nova]> select hypervisor_hostname,address,count(*) from pci_devices JOIN compute_nodes on compute_nodes.id=compute_node_id group by hypervisor_hostname,address having count(*) > 1; +-+--+--+ | hypervisor_hostname | address | count(*) | +-+--+--+ | localhost | :05:00.0 |3 | | localhost | :05:00.1 |3 | | localhost | :83:01.0 |3 | | localhost | :83:01.1 |3 | | localhost | :83:01.2 |3 | | localhost | :83:01.3 |3 | | localhost | :83:01.4 |3 | | localhost | :83:01.5 |3 | | localhost | :83:01.6 |3 | | localhost | :83:01.7 |3 | | localhost | :83:02.0 |3 | | localhost | :83:02.1 |3 | | localhost | :83:02.2 |3 | | localhost | :83:02.3 |3 | | localhost | :83:02.4 |3 | | localhost | :83:02.5 |3 | | localhost | :83:02.6 |3 | | localhost | :83:02.7 |3 | | localhost | :83:03.0 |3 | | localhost | :83:03.1 |3 | | localhost | :83:03.2 |3 | | localhost | :83:03.3 |3 | | localhost | :83:03.4 |3 | | localhost | :83:03.5 |3 | | localhost | :83:03.6 |3 | | localhost | :83:03.7 |3 | | localhost | :83:04.0 |3 | | localhost
[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
Reviewed: https://review.openstack.org/385968 Committed: https://git.openstack.org/cgit/openstack/zun/commit/?id=9b805918882abcf36145ddd9ef6e69889273c5ec Submitter: Jenkins Branch:master commit 9b805918882abcf36145ddd9ef6e69889273c5ec Author: Iswarya_Vakati Date: Thu Oct 13 18:21:37 2016 +0530 Drop MANIFEST.in - it's not needed by pbr Zun already uses PBR:- setuptools.setup( setup_requires=['pbr>=1.8'], pbr=True) This patch removes `MANIFEST.in` file as pbr generates a sensible manifest from git files and some standard files and it removes the need for an explicit `MANIFEST.in` file. Change-Id: I30830509234c2e37759b97502bb9fd5a9e7036dd Closes-Bug:#1608980 ** Changed in: zun 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1631133] Re: nova's osapi_compute_workers is not valid (must be greater than 1)
Reviewed: https://review.openstack.org/385078 Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=38f98383d396d89b8f6047e57e5e606615ee5a16 Submitter: Jenkins Branch:master commit 38f98383d396d89b8f6047e57e5e606615ee5a16 Author: Dan Prince Date: Tue Oct 11 12:09:43 2016 -0400 Only set NovaWorkers in the non-default case This patch updates the t-h-t templates for nova services so that we only set the value of workers in the non-default case. TripleO has always defaulted the workers count to 0 and there was recently a regression in nova where they treat the default of 0 as invalid (a bug that may get fixed in nova but we don't want to wait on it) This patch avoids the issue by allowing the default value to be unset if the TripleO default of 0 is configured. Change-Id: I175977b88129d87caeb32332d47eb14816a6d5d4 Closes-bug: #1631133 ** Changed in: tripleo 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/1631133 Title: nova's osapi_compute_workers is not valid (must be greater than 1) Status in OpenStack Compute (nova): In Progress Status in tripleo: Fix Released Bug description: As of Nova e8436283e45b6716fb61d6f6590fadb5fb4ba45c commit TripleO now fails to deploy nova-api correctly. This is because our default value set osapi_compute_workers=0 and metadata_workers=0 and this is no longer valid. Nova now requires an integer greater than 0, or an empty string. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1631133/+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 1551504] Re: I/O (PCIe) Based NUMA Scheduling can't really achieve pci numa binding in some cases.
Having discussed this since, it's clear that this isn't a bug but a design decision. nova allows scheduling PCI devices on hosts without an exposed NUMA topology as this satisfies the majority of use cases. It would be possible to make this behavior configurable, but this is a feature request - not a bug - and would require a spec [1]. [1] https://review.openstack.org/#/c/361140/ ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1551504 Title: I/O (PCIe) Based NUMA Scheduling can't really achieve pci numa binding in some cases. Status in OpenStack Compute (nova): Invalid Bug description: 1. version kilo 2015.1.0, liberty this bug is base on BP: https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling In the current implementation scheme: /nova/pci/stats.py def _filter_pools_for_numa_cells(pools, numa_cells): # Some systems don't report numa node info for pci devices, in # that case None is reported in pci_device.numa_node, by adding None # to numa_cells we allow assigning those devices to instances with # numa topology numa_cells = [None] + [cell.id for cell in numa_cells] # If some compute nodes don't report numa node info for pci devices. Then these pci devices will be regarded as "belong to all numa node" to deal with by default. This can lead to a problem: Pci devices is not on the numa node which CPU\MEM on. In this way, the real purpose of I/O (PCIe) Based NUMA Scheduling is not reached. More serious is that the user will be wrong thought pci devices is on the numa node that CPU\MEM on. The truth is, there are still many systems don't report numa node info for pci devices. So, i think this bug need fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1551504/+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 1618513] Re: nova quota policy with details seems broken
Fix proposed to branch: master Review: https://review.openstack.org/386008 ** Changed in: nova Status: Invalid => In Progress ** Changed in: nova Assignee: stgleb (gstepanov) => Andrey Volkov (avolkov) -- 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/1618513 Title: nova quota policy with details seems broken Status in OpenStack Compute (nova): In Progress Bug description: The default policy for this call: novaclient(request).quotas.get(tenant_id, detail=True) fails unless I am an admin type user. This doesn't seem to make sense, as an _member_ type user, I can still find all the details just the same. This just makes user do many more calls and calculations to work around this. The default policy file should be that if you are the member of the project, you can see the details if you want. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1618513/+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 1633084] Re: Secondary IPv6 subnet never gets configured in router
Doh, I'm an idiot, john-davidge pointed out I forgot to add the router interface to this subnet, I should know better :) ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633084 Title: Secondary IPv6 subnet never gets configured in router Status in neutron: Invalid Bug description: I brought up a devstack recently, which creates both internal IPv4 and IPv6 subnets on a single network. To test a bug fix I wanted to add a secondary IPv6 subnet on the network, so using Horizon I did that (since a subnetpool was already configured), such that: $ neutron net-list --field name --field subnets +-+---+ | name| subnets | +-+---+ | public | 32df3f47-2cc0-491f-a9dc-6a9b06287444 | | | ca7291e9-0470-49fe-80a7-63eddd73b338 | | private | ecaa0a78-646a-46fe-9846-996eddf70cf1 2001:db8:8000:1::/64 | | | afa2f586-4f8c-4951-800f-8f82bb37bc8c 2001:db8:8000::/64 | | | dd467ff5-5c9a-4cfe-91c9-fb788fc7ff40 10.0.0.0/24 | +-+---+ The 2001:db8:8000:1::/64 never got configured in my router, although it does show up in the DB. It's not in the namespace or radvd.conf file, so VMs don't autoconfigure it. $ sudo ip netns exec qrouter-f76baa3f-5881-4c49-8e72-cef86fa03166 ip a 1: lo: mtu 65536 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 46: qr-7f0792c8-39: mtu 1450 link/ether fa:16:3e:73:90:28 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-7f0792c8-39 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe73:9028/64 scope link valid_lft forever preferred_lft forever 49: qr-936fd0dc-71: mtu 1450 link/ether fa:16:3e:ed:78:be brd ff:ff:ff:ff:ff:ff inet6 2001:db8:8000::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:feed:78be/64 scope link valid_lft forever preferred_lft forever And here's the two subnet's info, which seems pretty identical except for the prefix: $ neutron subnet-show ipv6-private-subnet +---+-+ | Field | Value | +---+-+ | allocation_pools | {"start": "2001:db8:8000::2", "end": "2001:db8:8000:0::::"} | | cidr | 2001:db8:8000::/64 | | created_at| 2016-10-05T20:50:32Z | | description | | | dns_nameservers | | | enable_dhcp | True | | gateway_ip| 2001:db8:8000::1 | | host_routes | | | id| afa2f586-4f8c-4951-800f-8f82bb37bc8c | | ip_version| 6 | | ipv6_address_mode | slaac | | ipv6_ra_mode | slaac | | name | ipv6-private-subnet | | network_id| f6b05fa1-29e4-4e2f-96ae-d9f4cdededea | | project_id| df427083b46c400e956f66ba952b3b55 | | revision_number | 2 | | service_types | | | subnetpool_id | 79e46698-bc5a-4458-bed9-6d2a47d7876c | | tenant_id | df427083b46c400e956f66ba952b3b55 | | updated_at| 2016-10-05T20:50:32Z
[Yahoo-eng-team] [Bug 1633084] [NEW] Secondary IPv6 subnet never gets configured in router
Public bug reported: I brought up a devstack recently, which creates both internal IPv4 and IPv6 subnets on a single network. To test a bug fix I wanted to add a secondary IPv6 subnet on the network, so using Horizon I did that (since a subnetpool was already configured), such that: $ neutron net-list --field name --field subnets +-+---+ | name| subnets | +-+---+ | public | 32df3f47-2cc0-491f-a9dc-6a9b06287444 | | | ca7291e9-0470-49fe-80a7-63eddd73b338 | | private | ecaa0a78-646a-46fe-9846-996eddf70cf1 2001:db8:8000:1::/64 | | | afa2f586-4f8c-4951-800f-8f82bb37bc8c 2001:db8:8000::/64 | | | dd467ff5-5c9a-4cfe-91c9-fb788fc7ff40 10.0.0.0/24 | +-+---+ The 2001:db8:8000:1::/64 never got configured in my router, although it does show up in the DB. It's not in the namespace or radvd.conf file, so VMs don't autoconfigure it. $ sudo ip netns exec qrouter-f76baa3f-5881-4c49-8e72-cef86fa03166 ip a 1: lo: mtu 65536 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 46: qr-7f0792c8-39: mtu 1450 link/ether fa:16:3e:73:90:28 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-7f0792c8-39 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe73:9028/64 scope link valid_lft forever preferred_lft forever 49: qr-936fd0dc-71: mtu 1450 link/ether fa:16:3e:ed:78:be brd ff:ff:ff:ff:ff:ff inet6 2001:db8:8000::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:feed:78be/64 scope link valid_lft forever preferred_lft forever And here's the two subnet's info, which seems pretty identical except for the prefix: $ neutron subnet-show ipv6-private-subnet +---+-+ | Field | Value | +---+-+ | allocation_pools | {"start": "2001:db8:8000::2", "end": "2001:db8:8000:0::::"} | | cidr | 2001:db8:8000::/64 | | created_at| 2016-10-05T20:50:32Z | | description | | | dns_nameservers | | | enable_dhcp | True | | gateway_ip| 2001:db8:8000::1 | | host_routes | | | id| afa2f586-4f8c-4951-800f-8f82bb37bc8c | | ip_version| 6 | | ipv6_address_mode | slaac | | ipv6_ra_mode | slaac | | name | ipv6-private-subnet | | network_id| f6b05fa1-29e4-4e2f-96ae-d9f4cdededea | | project_id| df427083b46c400e956f66ba952b3b55 | | revision_number | 2 | | service_types | | | subnetpool_id | 79e46698-bc5a-4458-bed9-6d2a47d7876c | | tenant_id | df427083b46c400e956f66ba952b3b55 | | updated_at| 2016-10-05T20:50:32Z | +---+-+ $ neutron subnet-show ipv6-subnet-2 +---+---+ | Field | Value | +---+---+ | allocation_pools | {"start": "2001:db8:8000:1::2", "end": "2001:db8
[Yahoo-eng-team] [Bug 1632981] Re: keystone delete role gives no output when operation is successful
this is as-designed. no delete operations give feedback. just as in linux if something does not give you an error, you can assume it occurred just fine. https://www.quora.com/What-is-the-appropriate-HTTP-response-code-to-a -successful-DELETE-request ** Changed in: keystone Status: New => Invalid -- 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/1632981 Title: keystone delete role gives no output when operation is successful Status in OpenStack Identity (keystone): Invalid Bug description: When a role is deleted, no output is displayed on screen. This is vague. A confirmation should be generated for the user to avoid ambiguity. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1632981/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: zun Importance: Undecided Status: New ** Changed in: zun Assignee: (unassigned) => iswarya vakati (v-iswarya) ** Also affects: watcher Importance: Undecided Status: New ** Changed in: watcher Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: New Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633066] [NEW] Input int value into service_type list hit internal error
Public bug reported: I use REST api to create/update subnet with serive_types. I use some int type values in the list. The creation body is: { "subnet": { "network_id": "0d04102a-ba15-4d6c-94ee-8ac480cbb1ba", "name": "hellowor", "cidr": "99.99.99.99/24", "service_types" : ["network:1",2,3], "ip_version": 4 } } neutron server hit internal error. 2016-10-13 17:44:27.842 ERROR neutron.api.v2.resource [req-b9846c07-3574-4094-b6fe-ca978c1d31ce admin 488da3aab0ff45df9e85e17e7f89fedd] create failed: No details. 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource Traceback (most recent call last): 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/resource.py", line 79, in resource 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource result = method(request=request, **args) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 430, in create 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return self._create(request, body, **kwargs) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py", line 88, in wrapped 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource setattr(e, '_RETRY_EXCEEDED', True) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource self.force_reraise() 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py", line 84, in wrapped 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return f(*args, **kwargs) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource ectxt.value = e.inner_exc 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource self.force_reraise() 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return f(*args, **kwargs) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py", line 124, in wrapped 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource traceback.format_exc()) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource self.force_reraise() 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/db/api.py", line 119, in wrapped 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return f(*dup_args, **dup_kwargs) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 439, in _create 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource allow_bulk=self._allow_bulk) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 719, in prepare_request_body 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource attributes.convert_value(attr_info, res_dict, webob.exc.HTTPBadRequest) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/attributes.py", line 431, in convert_value 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource res = validator(res_dict[attr], attr_vals['validate'][rule]) 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/extensions/subnet_service_types.py", line 47, in _validate_subnet_service_types 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource not service_type.startswith(tuple(prefixes))): 2016-10-13 17:44:27.842 TRACE neutron.api.v2.resou
[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: solum Importance: Undecided Status: New ** Changed in: solum Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: trove Importance: Undecided Status: New ** Changed in: trove Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): New Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633047] [NEW] Nova - boot from volume - Min Disk Size - Liberty
Public bug reported: Description === Seemingly incorrect validation of image requirements for instance when using boot from volume functionality. Steps to reproduce == * Create an image with a minimum disk size (Eg 2GB) * Create a bootable volume from image (Eg 2GB) * Launch an flavor with 1GB RAM (root disk set to 40Gb in our case, but not expected to be used during boot from volume). Expected result === In this case the instance should be created, as the image minimum requirements are met. Actual result = Volume is smaller than the minimum size specified in image metadata. Volume size is 1073741824 bytes, minimum size is 2147483648 bytes This is incorrect volume size is LARGER than nova api is reporting, we thought this may be reporting the RAM size, rather than the disk size, however we disproved this by doubling the minimum disk size, and using a 2GB RAM instance. This succeeded. Stumpt! For now, we have removed minimum disk sizes. Environment === 1. OpenStack Liberty on Ubuntu14.04 w/ Ceph Jewel. dpkg -l |grep nova ii nova-api 2:12.0.3-0ubuntu1~cloud0 2. Libvirt+KVM (Unrelated, fails/refused(400) during API Call. 3. CEPH backed volumes/images and ephemeral disks 4. Neutron in use, but i expect also unrelated. Logs & Configs == The main log is the following. 2016-10-13 10:21:01.471 24901 DEBUG nova.api.openstack.wsgi Returning 400 to user: Volume is smaller than the minimum size specified in image metadata. Volume size is 1073741824 bytes, minimum size is 2147 483648 bytes. __call__ /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:1175 ** 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/1633047 Title: Nova - boot from volume - Min Disk Size - Liberty Status in OpenStack Compute (nova): New Bug description: Description === Seemingly incorrect validation of image requirements for instance when using boot from volume functionality. Steps to reproduce == * Create an image with a minimum disk size (Eg 2GB) * Create a bootable volume from image (Eg 2GB) * Launch an flavor with 1GB RAM (root disk set to 40Gb in our case, but not expected to be used during boot from volume). Expected result === In this case the instance should be created, as the image minimum requirements are met. Actual result = Volume is smaller than the minimum size specified in image metadata. Volume size is 1073741824 bytes, minimum size is 2147483648 bytes This is incorrect volume size is LARGER than nova api is reporting, we thought this may be reporting the RAM size, rather than the disk size, however we disproved this by doubling the minimum disk size, and using a 2GB RAM instance. This succeeded. Stumpt! For now, we have removed minimum disk sizes. Environment === 1. OpenStack Liberty on Ubuntu14.04 w/ Ceph Jewel. dpkg -l |grep nova ii nova-api 2:12.0.3-0ubuntu1~cloud0 2. Libvirt+KVM (Unrelated, fails/refused(400) during API Call. 3. CEPH backed volumes/images and ephemeral disks 4. Neutron in use, but i expect also unrelated. Logs & Configs == The main log is the following. 2016-10-13 10:21:01.471 24901 DEBUG nova.api.openstack.wsgi Returning 400 to user: Volume is smaller than the minimum size specified in image metadata. Volume size is 1073741824 bytes, minimum size is 2147 483648 bytes. __call__ /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:1175 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633047/+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 1633042] [NEW] L3 scheduler: make RouterL3AgentBinding always concurrently safe
Public bug reported: Changeset I3447ea5bcb7c57365c6f50efe12a1671e86588b3 added a binding_index column to the RouterL3AgentBinding table, which is unique with the router_id. However, the current logic isn't concurrent safe as some concurrent cases can raise a DBDuplicateEntry (if the same binding_index is being used by 2 different workers). ** Affects: neutron Importance: Medium Assignee: John Schwarz (jschwarz) Status: In Progress ** Tags: l3-dvr-backlog l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633042 Title: L3 scheduler: make RouterL3AgentBinding always concurrently safe Status in neutron: In Progress Bug description: Changeset I3447ea5bcb7c57365c6f50efe12a1671e86588b3 added a binding_index column to the RouterL3AgentBinding table, which is unique with the router_id. However, the current logic isn't concurrent safe as some concurrent cases can raise a DBDuplicateEntry (if the same binding_index is being used by 2 different workers). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633042/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => Shashi (shashi-kant) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: New Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: New Status in Tricircle: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633033] [NEW] live migration with encrypted volume fails
Public bug reported: When live migrating an instance with an encrypted volume it fails to detach the encrypted volume from the source and attaches at the target as an unencrypted volume. I do see the encrypted volume connector on the source but not on the target ls -l /dev/disk/by-path total 0 lrwxrwxrwx 1 root root 121 Oct 13 10:26 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1 -> /dev/mapper/crypt-ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1 lrwxrwxrwx 1 root root 9 Oct 13 10:36 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1 -> ../../sdd Target ls -l /dev/disk/by-path total 0 lrwxrwxrwx 1 root root 9 Oct 13 10:48 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1 -> ../../sdb lrwxrwxrwx 1 root root 9 Oct 13 10:48 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1 -> ../../sdc The instance can still access encrypted volume, but the data disappears when you umount/mount the device so I guess it looked ok at first due to filesystem caching The live migration fails in post migrate on the source due to an error trying to detach the encrypted volume (see bug https://bugs.launchpad.net/os-brick/+bug/1631318, which I'll close now) Subsequent attempts to detach the volume from the instance (after manually updating it to say it is on the target and active, see https://bugs.launchpad.net/nova/+bug/1628606. ** 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/1633033 Title: live migration with encrypted volume fails Status in OpenStack Compute (nova): New Bug description: When live migrating an instance with an encrypted volume it fails to detach the encrypted volume from the source and attaches at the target as an unencrypted volume. I do see the encrypted volume connector on the source but not on the target ls -l /dev/disk/by-path total 0 lrwxrwxrwx 1 root root 121 Oct 13 10:26 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1 -> /dev/mapper/crypt-ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1 lrwxrwxrwx 1 root root 9 Oct 13 10:36 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1 -> ../../sdd Target ls -l /dev/disk/by-path total 0 lrwxrwxrwx 1 root root 9 Oct 13 10:48 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1 -> ../../sdb lrwxrwxrwx 1 root root 9 Oct 13 10:48 ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1 -> ../../sdc The instance can still access encrypted volume, but the data disappears when you umount/mount the device so I guess it looked ok at first due to filesystem caching The live migration fails in post migrate on the source due to an error trying to detach the encrypted volume (see bug https://bugs.launchpad.net/os-brick/+bug/1631318, which I'll close now) Subsequent attempts to detach the volume from the instance (after manually updating it to say it is on the target and active, see https://bugs.launchpad.net/nova/+bug/1628606. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633033/+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 1618766] Re: Add new configuration test in sanity check: vf_extended_management
Reviewed: https://review.openstack.org/369811 Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=c9bdbf3c321b949e01a58d9397febabb067fbb5d Submitter: Jenkins Branch:master commit c9bdbf3c321b949e01a58d9397febabb067fbb5d Author: chenxing Date: Wed Sep 14 04:37:40 2016 + [cli-reference] add a new sanity check parameter Change-Id: I88b666522b8e21297657605b83d10174847e64fa Closes-Bug: #1618766 ** Changed in: openstack-manuals 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/1618766 Title: Add new configuration test in sanity check: vf_extended_management Status in neutron: Invalid Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/351833 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit a2dc3c35e3d35c6a5f2099fee819e87b4fa216e9 Author: Rodolfo Alonso Hernandez Date: Mon Jul 18 11:52:12 2016 +0100 Add new configuration test in sanity check: vf_extended_management This test will check if 'ip link' version installed in this server supports extended VF management parameter 'min_tx_rate'. This parameter set the minimum egress rate for an interface. This test is executed when SR-IOV back-end and QoS extension are enabled. DocImpact Partial-Bug: #1560963 Change-Id: Ie9334f4ad2f6b047bf56689edfa8a612364a To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1618766/+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 1633006] [NEW] Post metering-label-rules API returns 500 when the body has wrong metering_label_id
Public bug reported: When we calls metering-label-rules POST API with wrong metering_label_id, we catch 500 from Neutron server. $ curl -g -i -X POST http://127.0.0.1:9696/v2.0/metering/metering-label-rules.json -H "User-Agent: python-neutronclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN" -d '{"metering_label_rule": {"remote_ip_prefix": "10.0.0.0/24", "direction": "ingress", "metering_label_id": "43e7dfd6-0deb-427b-9abc-5eaf5ada5040"}}' HTTP/1.1 500 Internal Server Error Content-Type: application/json Content-Length: 150 X-Openstack-Request-Id: req-7242ca76-283a-4589-ae69-7214622b804b Date: Thu, 13 Oct 2016 09:22:43 GMT {"NeutronError": {"message": "Request Failed: internal server error while processing your request.", "type": "HTTPInternalServerError", "detail": ""}} Error log: 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1019, in _read_query_result 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource result.read() 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1302, in read 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource first_packet = self.connection._read_packet() 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 981, in _read_packet 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource packet.check_error() 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 393, in check_error 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource err.raise_mysql_exception(self._data) 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/err.py", line 107, in raise_mysql_exception 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource raise errorclass(errno, errval) 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource DBReferenceError: (pymysql.err.IntegrityError) (1452, u'Cannot add or update a child row: a foreign key constraint fails (`neutron`.`meteringlabelrules`, CONSTRAINT `meteringlabelrules_ibfk_1` FOREIGN KEY (`metering_label_id`) REFERENCES `meteringlabels` (`id`) ON DELETE CASCADE)') [SQL: u'INSERT INTO meteringlabelrules (id, direction, remote_ip_prefix, metering_label_id, excluded) VALUES (%(id)s, %(direction)s, %(remote_ip_prefix)s, %(metering_label_id)s, %(excluded)s)'] [parameters: {'remote_ip_prefix': u'10.0.0.0/24', 'direction': u'ingress', 'metering_label_id': u'43e7dfd6-0deb-427b-9abc-5eaf5ada5040', 'id': 'ee5358b7-7326-42d2-be37-829b97f945af', 'excluded': 0}] ** Affects: neutron Importance: Low Assignee: Hirofumi Ichihara (ichihara-hirofumi) Status: In Progress ** Tags: metering ** Changed in: neutron Assignee: (unassigned) => Hirofumi Ichihara (ichihara-hirofumi) ** Tags added: metering ** Changed in: neutron Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633006 Title: Post metering-label-rules API returns 500 when the body has wrong metering_label_id Status in neutron: In Progress Bug description: When we calls metering-label-rules POST API with wrong metering_label_id, we catch 500 from Neutron server. $ curl -g -i -X POST http://127.0.0.1:9696/v2.0/metering/metering-label-rules.json -H "User-Agent: python-neutronclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN" -d '{"metering_label_rule": {"remote_ip_prefix": "10.0.0.0/24", "direction": "ingress", "metering_label_id": "43e7dfd6-0deb-427b-9abc-5eaf5ada5040"}}' HTTP/1.1 500 Internal Server Error Content-Type: application/json Content-Length: 150 X-Openstack-Request-Id: req-7242ca76-283a-4589-ae69-7214622b804b Date: Thu, 13 Oct 2016 09:22:43 GMT {"NeutronError": {"message": "Request Failed: internal server error while processing your request.", "type": "HTTPInternalServerError", "detail": ""}} Error log: 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1019, in _read_query_result 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource result.read() 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1302, in read 2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource
[Yahoo-eng-team] [Bug 1632987] [NEW] _nova_to_osvif_vif_bridge: 'module' object has no attribute 'vif'
Public bug reported: Description === The unit-test "nova.tests.unit.virt.test_virt_drivers.LibvirtConnTestCase.test_set_admin_password" fails. I could narrow it down to this commit: https://github.com/openstack/nova/commit/735f710 move os_vif.initialize() to nova-compute start os_vif.initialize() was previously executed during module load. This means it was entirely possible that it was run before things like logging were actually set up in the expected way. Move this back into execution time instead of load time to ensure that logging is actually setup. Changes need to be made to tests which make assumptions about os_vif objects to manually initialize os_vif when it will be used. os_vif objects can't be created until it is initialized, so some delayed object creation is also done in test_vif.py. Closes-Bug: #1615676 Change-Id: I89fe5c5b3d762f3a3238b587685df85d15ee56c4 Steps to reproduce == A chronological list of steps which will bring off the issue you noticed: * Clone/pull nova * tox -e py27 nova.tests.unit.virt.test_virt_drivers.LibvirtConnTestCase.test_set_admin_password -r Expected result === Test should succeed Actual result = == Failed 1 tests - output below: == nova.tests.unit.virt.test_virt_drivers.LibvirtConnTestCase.test_set_admin_password -- Captured traceback: ~~~ Traceback (most recent call last): File "nova/tests/unit/virt/test_virt_drivers.py", line 58, in wrapped_func return f(self, *args, **kwargs) File "/home/markus/git/nova/.tox/py27/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova/tests/unit/virt/test_virt_drivers.py", line 980, in test_set_admin_password instance, network_info = self._get_running_instance(obj=True) File "nova/tests/unit/virt/test_virt_drivers.py", line 261, in _get_running_instance [], 'herp', network_info=network_info) File "nova/virt/libvirt/driver.py", line 2602, in spawn write_to_disk=True) File "nova/virt/libvirt/driver.py", line 4651, in _get_guest_xml context) File "nova/virt/libvirt/driver.py", line 4483, in _get_guest_config flavor, virt_type, self._host) File "nova/virt/libvirt/vif.py", line 507, in get_config vif_obj = os_vif_util.nova_to_osvif_vif(vif) File "nova/network/os_vif_util.py", line 369, in nova_to_osvif_vif vifobj = func(vif) File "nova/network/os_vif_util.py", line 248, in _nova_to_osvif_vif_bridge objects.vif.VIFBridge, AttributeError: 'module' object has no attribute 'vif' Captured pythonlogging: ~~~ 2016-10-13 10:12:16,176 INFO [248_add_expire_reservations_index] Skipped adding reservations_deleted_expire_idx because an equivalent index already exists. 2016-10-13 10:12:18,153 INFO [os_brick.initiator.connectors.disco] Init DISCO connector 2016-10-13 10:12:18,153 WARNING [os_brick.initiator.connectors.remotefs] Connection details not present. RemoteFsClient may not initialize properly. 2016-10-13 10:12:18,209 INFO [nova.virt.osinfo] Cannot load Libosinfo: (No module named gi.repository.Libosinfo) 2016-10-13 10:12:18,209 INFO [nova.virt.libvirt.driver] Creating image 2016-10-13 10:12:18,258 INFO [nova.virt.libvirt.driver] Connection event '1' reason 'None' 2016-10-13 10:12:18,260 INFO [nova.virt.libvirt.host] Libvirt host capabilities cef19ce0-0ca2-11df-855d-b19fbce37686 x86_64 Penryn Intel tcp apparmor 0 hvm 32 /usr/bin/qemu pc-0.14 pc pc-0.13 pc-0.12 pc-0.11 pc-0.10 isapc /usr/bin/kvm pc-0.14 pc pc-0.13 pc-0.12 pc-0.11 pc-0.10 isapc
[Yahoo-eng-team] [Bug 1632981] [NEW] keystone delete role gives no output when operation is successful
Public bug reported: When a role is deleted, no output is displayed on screen. This is vague. A confirmation should be generated for the user to avoid ambiguity. ** Affects: keystone Importance: Undecided Status: New ** Tags: keystone role -- 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/1632981 Title: keystone delete role gives no output when operation is successful Status in OpenStack Identity (keystone): New Bug description: When a role is deleted, no output is displayed on screen. This is vague. A confirmation should be generated for the user to avoid ambiguity. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1632981/+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