[Yahoo-eng-team] [Bug 1840927] [NEW] Rewrite doc on L2 population
Public bug reported: In the Networking Guide back in Kilo https://docs.openstack.org/neutron/latest/admin/config-ml2.html there was a section on L2 population. This section no longer exists, and nothing similar is in existance. As a replacement, this blog post was used in the documentation: https://networkop.co.uk/blog/2016/05/06/neutron-l2pop/ as per this review: https://review.opendev.org/#/c/676920/ It would be best if this knowledge could be transferred. Thanks, Alex ** Affects: neutron Importance: Undecided Status: New ** Tags: docs ** Tags added: docs -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1840927 Title: Rewrite doc on L2 population Status in neutron: New Bug description: In the Networking Guide back in Kilo https://docs.openstack.org/neutron/latest/admin/config-ml2.html there was a section on L2 population. This section no longer exists, and nothing similar is in existance. As a replacement, this blog post was used in the documentation: https://networkop.co.uk/blog/2016/05/06/neutron-l2pop/ as per this review: https://review.opendev.org/#/c/676920/ It would be best if this knowledge could be transferred. Thanks, Alex To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1840927/+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 1809578] Re: Documentation might be wront
** Project changed: openstack-manuals => neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1809578 Title: Documentation might be wront Status in neutron: New Bug description: - [x] This doc is inaccurate in this way: firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver is leading to no firewall driver found in logs. - [x] I have a fix to the document that I can paste below including example: input and output. I just changed it to firewall_driver = iptables (suggested on the net) --- Release: 0.1 on 2018-01-26 00:18 SHA: 3d7f0be2be0108912bae26e9333e825d929f4943 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/neutron-compute-install-option2.rst URL: https://docs.openstack.org/newton/install-guide-debian/neutron-compute-install-option2.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1809578/+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 1701614] Re: Booting from an encrypted volume
This should mostly be merged to appropriate repo now. This can be updated. ** Changed in: openstack-manuals Status: In Progress => Confirmed ** Also affects: nova Importance: Undecided Status: New ** Changed in: openstack-manuals Status: Confirmed => Won't Fix ** Changed in: nova Status: New => Confirmed -- 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/1701614 Title: Booting from an encrypted volume Status in OpenStack Compute (nova): Confirmed Status in openstack-manuals: Won't Fix Bug description: The user guide currently has a section describing how to import a bootable image into a volume, but it doesn't include instructions on how to import an image into an encrypted volume and boot from it. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0 on 2017-06-30 05:27 SHA: a1f1748478125ccd68d90a98ccc06c7ec359d3a0 Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/source/cli-nova-launch-instance-from-volume.rst URL: https://docs.openstack.org/user-guide/cli-nova-launch-instance-from-volume.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1701614/+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 1696264] Re: Create OpenStack client environment scripts in Installation Guide INCOMPLETE - doesn't state path for file
** 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 OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1696264 Title: Create OpenStack client environment scripts in Installation Guide INCOMPLETE - doesn't state path for file Status in OpenStack Identity (keystone): Fix Released Status in openstack-manuals: Fix Released Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [X] This doc is inaccurate in this way: It says to create a file but doesn't say where... so I can't. So I'm stuck. - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0 on 2017-06-02 17:52 SHA: 3d8b9d021dd5f85bb0f0232a0475271d7f5537fc Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/keystone-openrc.rst URL: https://docs.openstack.org/ocata/install-guide-ubuntu/keystone-openrc.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1696264/+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 1698455] Re: Install and configure in Installation Guide: Populate the Identity service database step fails on CentOS7
** Project changed: openstack-manuals => keystone ** Changed in: keystone Status: Confirmed => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1698455 Title: Install and configure in Installation Guide: Populate the Identity service database step fails on CentOS7 Status in OpenStack Identity (keystone): New Bug description: - [X] This doc is inaccurate in this way: Failure in step "3. Populate the Identity service database:" of https://docs.openstack.org/ocata/install-guide-rdo/keystone-install.html su -s /bin/sh -c "keystone-manage db_sync" keystone A similar problem has been reported at https://ask.openstack.org/en/question/52838/error-when-creating-administrative-tenant-cento7-juno/ How to reproduce: [root@controller ~]# whoami root [root@controller ~]# hostname controller [root@controller ~]# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) [root@controller ~]# rpm -q centos-release-openstack-ocata centos-release-openstack-ocata-1-1.el7.noarch [root@controller ~]# rpm -q mariadb-server mariadb-server-10.1.20-1.el7.x86_64 [root@controller ~]# echo 'SHOW GRANTS FOR keystone' | mysql -uroot -pDBpass Grants for keystone@% GRANT USAGE ON *.* TO 'keystone'@'%' IDENTIFIED BY PASSWORD '*61D672B503D8DD7C9992AA31B0AC5B7DC43887AB' GRANT ALL PRIVILEGES ON `keystone`.* TO 'keystone'@'%' [root@controller ~]# echo 'SELECT HOST, USER from user\G' | mysql -uroot -pDBpass mysql *** 1. row *** HOST: % USER: keystone *** 2. row *** HOST: 127.0.0.1 USER: root *** 3. row *** HOST: ::1 USER: root *** 4. row *** HOST: localhost USER: keystone *** 5. row *** HOST: localhost USER: root [root@controller ~]# echo > /var/log/keystone/keystone.log [root@controller ~]# su -s /bin/sh -c "keystone-manage db_sync" keystone; echo $? 1 [root@controller ~]# tail /var/log/keystone/keystone.log 2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1124, in _request_authentication 2017-06-16 20:04:40.519 17512 ERROR keystone auth_packet = self._read_packet() 2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 991, in _read_packet 2017-06-16 20:04:40.519 17512 ERROR keystone packet.check_error() 2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 393, in check_error 2017-06-16 20:04:40.519 17512 ERROR keystone err.raise_mysql_exception(self._data) 2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/err.py", line 107, in raise_mysql_exception 2017-06-16 20:04:40.519 17512 ERROR keystone raise errorclass(errno, errval) 2017-06-16 20:04:40.519 17512 ERROR keystone OperationalError: (pymysql.err.OperationalError) (1045, u"Access denied for user 'keystone'@'controller' (using \ password: YES)") 2017-06-16 20:04:40.519 17512 ERROR keystone - [X] I have a fix to the document that I can paste below including example: input and output. A possible solution is to add a grant for 'keystone'@'controller' in the "Grant proper access to the keystone database" section: [root@controller ~]# echo "GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'controller' IDENTIFIED BY 'KEYSTONE_DBPASS';" | mysql -uroot -pDBpass [root@controller ~]# echo > /var/log/keystone/keystone.log [root@controller ~]# su -s /bin/sh -c "keystone-manage db_sync" keystone; echo $? 0 --- Release: 15.0.0 on 2017-06-12 16:28 SHA: 839afb2adab31b0a283c212fc73bc82d4775e7f4 Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/keystone-install.rst URL: https://docs.openstack.org/ocata/install-guide-rdo/keystone-install.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1698455/+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 1544044] Re: Add new API to force live migration to complete
** Changed in: openstack-manuals Assignee: Alexandra Settle (alexandra-settle) => (unassigned) ** Project changed: openstack-manuals => nova ** Tags added: doc -- 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/1544044 Title: Add new API to force live migration to complete Status in OpenStack Compute (nova): Confirmed Bug description: https://review.openstack.org/245921 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/nova" 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 c9091d0871948377685feca0eb2e41d8ad38228a Author: Pawel Koniszewski <pawel.koniszew...@intel.com> Date: Mon Feb 8 08:59:52 2016 +0100 Add new API to force live migration to complete This change adds manual knob to force ongoing live migration to complete. It is implemented as a new server-migrations API. DocImpact ApiImpact Implements: blueprint pause-vm-during-live-migration Change-Id: I034b4041414a797f65ede52db2963107f2ef7456 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1544044/+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 1670261] Re: Migrate a single instance to another compute host in Administrator Guide
** Project changed: openstack-manuals => nova ** Changed in: nova Status: Confirmed => 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/1670261 Title: Migrate a single instance to another compute host in Administrator Guide Status in OpenStack Compute (nova): New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [X] This doc is inaccurate in this way: Related to https://bugs.launchpad.net/openstack-manuals/+bug/1665860 and https://bugs.launchpad.net/openstack-manuals/+bug/1670225. The page mixes live and cold migration without making it clear. Some details: Wrong text: "The scheduler chooses the destination compute host". When using the openstack client to live-migrate an instance, the user has to provide the destination host (I haven't double-checked that in Ocata, but the current OSC documentation says so). The script in step 3 uses the "nova migrate" command instead of "openstack server migrate" and performs a cold migration, which is inconsistent with the live migration in step 2. Besides, the script could probably be simplified. To monitor live migration, "nova server-migration-list" and "nova server-migration-show" can be used for a much simpler script. Inconsistent text "The instance is booted from a new host" - this is true for cold migration, but not live migration. I would rewrite the page, giving examples for cold and live migration. - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 0.9 on 2017-03-06 05:22 SHA: ccf45727a00cc74789657833ca8947364e6f543a Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/admin-guide/source/cli-nova-migrate.rst URL: https://docs.openstack.org/admin-guide/cli-nova-migrate.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1670261/+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 1698254] Re: VMware vSphere in Configuration Reference
** Project changed: openstack-manuals => nova -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1698254 Title: VMware vSphere in Configuration Reference Status in OpenStack Compute (nova): Incomplete Bug description: Doc should mention that only provider network is configurable directly with some changes in vCenter like mentioning the creation of bridge steps. And the ways to use the self-service network with vCenter as a compute like NSX, openvswitch etc. and how to do it. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1698254/+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 1683651] Re: Policy.json for nova is removed in stable/ocata but the documentation still refers to editing the file for controlling actions
** Changed in: openstack-manuals Status: Confirmed => New ** Project changed: openstack-manuals => nova ** Changed in: nova Milestone: pike => None ** Changed in: nova Assignee: Njira Perci (njirap) => (unassigned) -- 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/1683651 Title: Policy.json for nova is removed in stable/ocata but the documentation still refers to editing the file for controlling actions Status in OpenStack Compute (nova): New Bug description: I could see that the policy.json file for nova has been removed for stable/ocata branch, but the documentation still refers for modifications of file incase a user wants to control the access. Below are the wordings: "By default, administrative users can configure the flavors. You can change this behavior by redefining the access controls for compute_extension:flavormanage in /etc/nova/policy.json on the compute-api server." Link to the document: https://docs.openstack.org/admin-guide/compute-images-instances.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1683651/+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 1682245] Re: The policy.json file in Configuration Reference - compute:get_all no longer exists
** Also affects: nova Importance: Undecided Status: New ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- 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/1682245 Title: The policy.json file in Configuration Reference - compute:get_all no longer exists Status in OpenStack Compute (nova): New Status in openstack-manuals: Won't Fix Bug description: - [x] This doc is inaccurate in this way: The "compute:get_all" example is no longer valid, that rule does not exist in Nova in Ocata. It did back in Mitaka, but in Newton the policy for Nova was all moved into code. The "compute:get_all" rule was for the old v2 API. With the v2.1 API the rule is now something like "os_compute_api:servers:index" or "os_compute_api:servers:detail" depending on the actual API that is called. This is a minor issue, very low severity, but the docs could be updated to replace "compute:get_all" with "os_compute_api:servers:detail" for the example. --- Release: 15.0.0 on 2017-04-10 10:26 SHA: 42e384ee11368ba8ad1545b6bd3042ee66954062 Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/config-reference/source/policy-json-file.rst URL: https://docs.openstack.org/ocata/config-reference/policy-json-file.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1682245/+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 1684261] Re: AggregateImagePropertiesIsolation example doesn't actually indicate how it works
** Changed in: openstack-manuals Assignee: Alexandra Settle (alexandra-settle) => (unassigned) ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- 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/1684261 Title: AggregateImagePropertiesIsolation example doesn't actually indicate how it works Status in OpenStack Compute (nova): Confirmed Status in openstack-manuals: Won't Fix Bug description: The AggregateImagePropertiesIsolation filter documentation in https://docs.openstack.org/ocata/config- reference/compute/schedulers.html does not actually effectively illustrate how the filter works. * "For example, the following aggregate myWinAgg has the Windows operating system as metadata (named ‘windows’):" - the subsequent `openstack aggregate show MyWinAgg` does not show any such metadata. * "In this example, because the following Win-2012 image has the windows property, it boots on the sf-devel host (all other filters being equal):" - the subsequent output for `openstack image show Win-2012` does not actually show the image properties (the output is truncated). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1684261/+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 1586208] Re: Scenario: Provider networks with Linux bridge in Networking Guide
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1586208 Title: Scenario: Provider networks with Linux bridge in Networking Guide Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: Not so much a bug than feedback. The page is not clear whether each node has a single Linux Bridge or several. Somebody with good networking skills might consider this common knowledge, but if you are not that versed in the field of datacenter networking (I am certainly not), you may be a bit lost. At some point, the page talks about the Linux Bridge Agent managing "switches" (plural; and why "switches" and not "bridges"?), but elsewhere there is only talk about one bridge named qbr (and sometimes brq. Better name it consistently!). I suggest the following change: - make it clear that there is one bridge per provider network, not a single bridge per compute and control node. Or am I wrong? (see, I am confused!) And these minor changes: - label the bridges consistently - if you call Linux Bridges "switches", explain why --- Release: 0.9 on 2016-05-25 13:08 SHA: 0671dca2730c636eaaca64f3880513bf7242e4b4 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/scenario-provider-lb.rst URL: http://docs.openstack.org/mitaka/networking-guide/scenario-provider-lb.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1586208/+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 1616114] Re: Flavors lack documentation
** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1616114 Title: Flavors lack documentation Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: Flavors [1] lack documentation, particularly for operators. Consider adding it to the networking guide. [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo /neutron-flavor-framework.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1616114/+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 1588984] Re: Improve IPAM documentation
** Changed in: openstack-manuals Status: Triaged => Won't Fix ** Tags added: autogenerate-config-docs ** Tags removed: autogenerate-config-docs ** Tags added: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1588984 Title: Improve IPAM documentation Status in neutron: Triaged Status in openstack-manuals: Won't Fix Bug description: Improve IPAM content in the Networking Guide [1]. Also decide whether to consider it a standard (usable in production) or experimental (incomplete) feature. [1] http://docs.openstack.org/mitaka/networking-guide/adv-config- ipam.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1588984/+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 1586213] Re: Scenario: Provider networks with Linux bridge in Networking Guide
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1586213 Title: Scenario: Provider networks with Linux bridge in Networking Guide Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: The use cases in the first part of the page present several provider networks plus an external network. The external network has IP addresses in the 203 range, the other provider networks use the 192 range. Instances are connected to 192. addresses. On the other hand, the second part Example Configuration creates a single network, which is also external, and connects the instance to it. IP addresses are 203.. Architecture and Packet Flow are explained at considerable detail. It's a pity that the Example Configuration doesn't use the scenarios developed in the first part of the page. I suggest to show the configuration of one external and two provider networks using the same IP address ranges 203... and 192... . --- Release: 0.9 on 2016-05-25 13:08 SHA: 0671dca2730c636eaaca64f3880513bf7242e4b4 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/scenario-provider-lb.rst URL: http://docs.openstack.org/mitaka/networking-guide/scenario-provider-lb.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1586213/+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 1617548] Re: Provide client bindings for DELETE method of auto-allocated-topology extension
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1617548 Title: Provide client bindings for DELETE method of auto-allocated- topology extension Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/359494 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/python-neutronclient" 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 ee6b6eafb7799f7066d437f826deb39bd3172c87 Author: Armando MigliaccioDate: Tue Aug 23 17:13:28 2016 -0700 Provide client bindings for DELETE method of auto-allocated-topology extension DocImpact: Add documentation for auto-allocate-topology-delete CLI Partial-bug: #1614872 Depends-on: I2fba51bdf8c781fcc0449e1e9947de976c96eec4 Change-Id: I07ef85e4a0c43613351820bd56e429d0155c9fa5 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1617548/+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 1652344] Re: Allow keystone v3 in the designate driver
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1652344 Title: Allow keystone v3 in the designate driver Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/398359 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 91d048dbde83a52f43aceebaf1b1e1ef0937602d Author: Gyorgy SzombathelyiDate: Wed Nov 16 14:37:38 2016 +0100 Allow keystone v3 in the designate driver Using the loader from keystoneauth1, it is possible to easily use keystone v3 options in [designate]. For the end user, it means she/he must specify designate.auth_type, then she/he can specify an Keystone v3 endpoint in designate.auth_url. Change-Id: I8bb02f11e60767dacdf6ac852979cfa82de1e08b Closes-bug: #1585976 DocImpact To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1652344/+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 1662478] Re: Add a deployment example that includes booting instances on router:external networks
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1662478 Title: Add a deployment example that includes booting instances on router:external networks Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: The discussion around [1] makes it clear that the networking guide currently lacks content for hybrid-style deployments that allow instances to be booted on both external and self-service networks. The amount of work required to add this content seems out of scope of the original bug report, so I'm closing it in favor of this one. See the original discussion, particularly [2] for details of the new content required. [1] https://bugs.launchpad.net/openstack-manuals/+bug/1046121 [2] https://bugs.launchpad.net/openstack-manuals/+bug/1046121/comments/13 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1662478/+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 1674632] Re: Open vSwitch: Self-service networks in Networking Guide
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1674632 Title: Open vSwitch: Self-service networks in Networking Guide Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: Hi, The steps for configuring openvswitch on Ubuntu for newton release is missing some vital information.When I followed the steps as they are, my instances are not getting floating ip. I think the docs are missing some important information like how to setup the OVS bridges for vlan networks. I remember that after the kilo release, the documentation on openvswitch mechanism in latest openstack releases has many gaps. I think its time for the openstack community to act and take the openvswitch implementation as seriously as possible like in the case of linux bridge. Openvswitch has much importance these days in the ares like NFV (Network Functions Virtualization) in Telco cloud. Please make sure that the use cases in the Documentation are validated before the release. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 0.9 on 2017-03-14 05:44 SHA: bb783d2e176f963eb28eac45c8c5c7bb794128dc Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/deploy-ovs-selfservice.rst URL: https://docs.openstack.org/newton/networking-guide/deploy-ovs-selfservice.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1674632/+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 1659710] Re: Transition qos notification driver into qos driver
Moving to neutron as per doc migration. ** Also affects: neutron Importance: Undecided Status: New ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1659710 Title: Transition qos notification driver into qos driver Status in neutron: New Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/396651 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 38c1812015b6977f8212723d08cefb0926e6 Author: Miguel Angel AjoDate: Thu Nov 17 09:17:29 2016 -0500 Transition qos notification driver into qos driver This will deprecate the notification_driver config setting, and no config setting will be needed. Also it lays down the foundation for a more decoupled interaction with mechanism drivers. Closes-Bug: #1657379 Related-Bug: #1627749 DocImpact Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659710/+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 1656378] Re: Networking Guide uses RFC1918 IPv4 ranges instead of RFC5737
Moved to the neutron repo :) ** Also affects: neutron Importance: Undecided Status: New ** Changed in: openstack-manuals Status: In Progress => Won't Fix ** Changed in: neutron 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/1656378 Title: Networking Guide uses RFC1918 IPv4 ranges instead of RFC5737 Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: ***UPDATE*** An etherpad for tracking the required changes can be found here: https://etherpad.openstack.org/p/non-compliant-ip-subnets Hi! I was reading the guide on the "Get me a network" bits, and I realized that the whole manual is using the wrong address ranges. RFC5737 defines three ranges for use in documentation: 3. Documentation Address Blocks The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation. These are non-routable addresses, even privately, and the RFC is specifically provided to avoid problems like overlap (If everyone uses the 10.x ranges because that's what's in the manuals, we end up with even more overlap than usual). https://tools.ietf.org/rfc/rfc5737.txt It's worth noting that the manual _is_ compliant with RFC3848, which defines the IPv6 documentation range as 2001:db8::/32. --- Release: 0.9 on 2017-01-12 12:47 SHA: 03c62feaf3779cc3b0491f83bcb5eb2dd3442e2a Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/config-auto-allocation.rst URL: http://docs.openstack.org/newton/networking-guide/config-auto-allocation.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1656378/+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 1660687] Re: L2 agent securitygroup config not documented
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1660687 Title: L2 agent securitygroup config not documented Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: This bug was generated after further inspecting [1]. IIUC based on [1], L2 agents with mixed securitygroup firewall drivers are now supported and can be achieved by setting the firewall_driver on each agent:: [securitygroup] firewall_driver = driver_for_agent This is then reported and used by neutron server (IIUC the server firewall_driver will be used if the agent doesn't report its driver for backwards compat). The mix approach appears to be reflected in the deploy OVS providers section of the networking guide (ex [2]). However when following/viewing the config ref for the L2 agents [3], the [securitygroups] section isn't even mentioned. For example [4]. I do see security groups documented in [5], but as a deployer/admin it's not clear how I associate [5] with the L2 agent configs [3]. Is there someway we can make it more clear that [5] is applicable to the L2 agents? [1] https://bugs.launchpad.net/neutron/+bug/1607724 [2] http://docs.openstack.org/newton/networking-guide/deploy-ovs-provider.html [3] http://docs.openstack.org/newton/networking-guide/config-ml2.html#agents [4] http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html#open-vswitch-agent-configuration-options [5] http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html#security-groups To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1660687/+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 1635468] Re: iptables: fail to start ovs/linuxbridge agents on missing sysctl knobs
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1635468 Title: iptables: fail to start ovs/linuxbridge agents on missing sysctl knobs Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/371523 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 e83a44b96a8e3cd81b7cc684ac90486b283a3507 Author: Ihar HrachyshkaDate: Thu Sep 15 21:48:10 2016 + iptables: fail to start ovs/linuxbridge agents on missing sysctl knobs For new kernels (3.18+), bridge module is split into two pieces: bridge and br_netfilter. The latter provides firewall support for bridged traffic, as well as the following sysctl knobs: * net.bridge.bridge-nf-call-arptables * net.bridge.bridge-nf-call-ip6tables * net.bridge.bridge-nf-call-iptables Before kernel 3.18, any brctl command was loading the 'bridge' module with the knobs, so at the moment where we reached iptables setup, they were always available. With new 3.18+ kernels, brctl still loads 'bridge' module, but not br_netfilter. So bridge existance no longer guarantees us knobs' presence. If we reach _enable_netfilter_for_bridges before the new module is loaded, then the code will fail, triggering agent resync. It will also fail to enable bridge firewalling on systems where it's disabled by default (examples of those systems are most if not all Red Hat/Fedora based systems), making security groups completely ineffective. Systems that don't override default settings for those knobs would work fine except for this exception in the log file and agent resync. This is because the first attempt to add a iptables rule using 'physdev' module (-m physdev) will trigger the kernel module loading. In theory, we could silently swallow missing knobs, and still operate correctly. But on second thought, it's quite fragile to rely on that implicit module loading. In the case where we can't detect whether firewall is enabled, it's better to fail than hope for the best. An alternative to the proposed path could be trying to fix broken deployment, meaning we would need to load the missing kernel module on agent startup. It's not even clear whether we can assume the operation would be available to us. Even with that, adding a rootwrap filter to allow loading code in the kernel sounds quite scary. If we would follow the path, we would also hit an issue of distinguishing between cases of built-in kernel module vs. modular one. A complexity that is probably beyond what Neutron should fix. The patch introduces a sanity check that would fail on missing configuration knobs. DocImpact: document the new deployment requirement in operations guide UpgradeImpact: deployers relying on agents fixing wrong sysctl defaults will need to make sure bridge firewalling is enabled. Also, the kernel module providing sysctl knobs must be loaded before starting the agent, otherwise it will fail to start. Depends-On: Id6bfd9595f0772a63d1096ef83ebbb6cd630fafd Change-Id: I9137ea017624ac92a05f73863b77f9ee4681bbe7 Related-Bug: #1622914 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1635468/+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 1682021] Re: Routed provider networks in Networking Guide: Wrong URL
** Also affects: neutron Importance: Undecided Status: New ** Changed in: openstack-manuals Status: In Progress => Won't Fix ** Changed in: neutron 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/1682021 Title: Routed provider networks in Networking Guide: Wrong URL Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [X] This doc is inaccurate in this way: Section "Create a routed provider network", point 9, accesses the placement API. On my packstack deployment, placement API endpoints are configured with port number 8778. It should be mentioned that the URL might be different depending on the deployment, and that it can be found with openstack endpoint list | grep placement. --- Release: 15.0.0 on 2017-04-10 10:24 SHA: 42e384ee11368ba8ad1545b6bd3042ee66954062 Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/config-routed-networks.rst URL: https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1682021/+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 1686656] Re: Firewall-as-a-Service (FWaaS) v2 scenario in Networking Guide
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Confirmed ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1686656 Title: Firewall-as-a-Service (FWaaS) v2 scenario in Networking Guide Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: Doc is wrong : "Enable the option in the local_settings.py file" in fact , the file name should be local_settings ,without the suffix ".py" This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 0.9 on 2017-04-18 13:41 SHA: 10e9fae269dfd026ad3357075334b454c66eb630 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/fwaas-v2-scenario.rst URL: https://docs.openstack.org/newton/networking-guide/fwaas-v2-scenario.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1686656/+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 1694349] Re: VXLAN multicast groups in linuxbridge
Moving back to the neutron repo. ** Changed in: openstack-manuals Status: Confirmed => Won't Fix ** Changed in: neutron Status: Invalid => 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/1694349 Title: VXLAN multicast groups in linuxbridge Status in neutron: Confirmed Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/79 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 8a596f35bb70a2c8ab48f68327662310141bb518 Author: Jiri KotlinDate: Thu Jun 23 14:04:07 2016 + VXLAN multicast groups in linuxbridge Enable creation of VXLANs with different multicast addresses allocated by VNI-address mappings. Dictionary of multicast addresses and corresponding VXLAN VNI IDs should be loaded from settings. Usable to not flood whole network when managing routers between more datacenters and can not use L2population because VXLAN points to external device. Co-Authored-By: Kevin Benton DocImpact: VXLAN addresses used by linux bridge can be specified per VNI Closes-Bug: #1579068 Change-Id: I24f272ccd6d61d9fa7ea3b6f256fabd381f5434a To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694349/+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 1708394] Re: Some URL in neutron's documentation cannot found(404).
Moving to neutron :) ** Project changed: openstack-manuals => neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1708394 Title: Some URL in neutron's documentation cannot found(404). Status in neutron: New Bug description: The documentation of neutron (https://docs.openstack.org/neutron/latest/) contains links to pages that not exist. https://docs.openstack.org/api/openstack-network/2.0/content/ https://docs.openstack.org/trunk/openstack-network/admin/content/index.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1708394/+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 1557119] Re: Services and Agents DevRef doesn't describe configuration seperation
** Changed in: openstack-manuals Status: In Progress => Fix Released ** Changed in: ossp-security-documentation Assignee: Rahul U Nair (rahulunair) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1557119 Title: Services and Agents DevRef doesn't describe configuration seperation Status in neutron: Fix Released Status in openstack-manuals: Fix Released Status in OpenStack Security Guide Documentation: New Bug description: Presently the services and agents DevRef doesn't describe how configuration options should be separated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1557119/+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 1684261] Re: AggregateImagePropertiesIsolation example doesn't actually indicate how it works
Adding nova to this bug report. I think some more working examples around that filter would benefit both the developer docs and the openstack-manuals doc. Currently there isn't anything concrete, really. ** Also 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/1684261 Title: AggregateImagePropertiesIsolation example doesn't actually indicate how it works Status in OpenStack Compute (nova): New Status in openstack-manuals: Confirmed Bug description: The AggregateImagePropertiesIsolation filter documentation in https://docs.openstack.org/ocata/config- reference/compute/schedulers.html does not actually effectively illustrate how the filter works. * "For example, the following aggregate myWinAgg has the Windows operating system as metadata (named ‘windows’):" - the subsequent `openstack aggregate show MyWinAgg` does not show any such metadata. * "In this example, because the following Win-2012 image has the windows property, it boots on the sf-devel host (all other filters being equal):" - the subsequent output for `openstack image show Win-2012` does not actually show the image properties (the output is truncated). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1684261/+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 1678561] Re: Update metering agent to use stevedore alias for driver
** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: openstack-manuals Status: New => Confirmed ** Changed in: openstack-manuals Importance: Undecided => Low ** Changed in: openstack-manuals Assignee: (unassigned) => Brian Haley (brian-haley) ** Tags added: admin-guide -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1678561 Title: Update metering agent to use stevedore alias for driver Status in neutron: Confirmed Status in openstack-manuals: Confirmed Bug description: https://review.openstack.org/419881 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 c9d46984096574d130465705ac68b9df272aaa98 Author: Jean-Philippe EvrardDate: Fri Jan 13 10:47:52 2017 + Update metering agent to use stevedore alias for driver Currently the metering agent is using the old import method, use stevedore instead. DocImpact Two places in the networking guide should change to 'driver = iptables' from current format. Partial-Bug: #1504536 Change-Id: I1e6d196a3ada8fbfc2b70d6a983984d8db09bbd0 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1678561/+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 1678475] Re: Apply QoS policy on network:router_gateway
** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: openstack-manuals Status: New => Confirmed ** Changed in: openstack-manuals Importance: Undecided => Low ** Changed in: openstack-manuals Assignee: (unassigned) => Maxime (maxime-guyot-p) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1678475 Title: Apply QoS policy on network:router_gateway Status in neutron: Confirmed Status in openstack-manuals: Confirmed Bug description: https://review.openstack.org/425218 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 2d1ee7add7c08ebbf8de7f9a0dc2aeb5344a4052 Author: Maxime GuyotDate: Wed Mar 8 15:14:32 2017 +0100 Apply QoS policy on network:router_gateway All router ports (internal and external) used to be excluded from QoS policies applied on network. This patch excludes only internal router ports from network QoS policies. This allows cloud administrators to set an egress QoS policy to a public/external network and have the QoS policy applied on all external router ports (DVR or not). To the tenant this is also egress traffic so no confusion compared to QoS policies applied to VM ports. DocImpact Update networking-guide/config-qos, User workflow section: - Replace "Network owned ports" with "Internal network owned ports" Change-Id: I2428c2466f41a022196576f4b14526752543da7a Closes-Bug: #1659265 Related-Bug: #1486039 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1678475/+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 1557119] Re: Services and Agents DevRef doesn't describe configuration seperation
** Changed in: openstack-manuals Status: Incomplete => Confirmed ** Tags added: networking-guide ** Also affects: ossp-security-documentation Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1557119 Title: Services and Agents DevRef doesn't describe configuration seperation Status in neutron: Fix Released Status in openstack-manuals: Confirmed Status in OpenStack Security Guide Documentation: New Bug description: Presently the services and agents DevRef doesn't describe how configuration options should be separated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1557119/+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 1662102] Re: Enhance tag mechanism
Copying across action items from duplicate bug #1662644: Armando Migliaccio (armando-migliaccio) wrote 12 hours ago: #1 We should probably make additions to the base stuff already captured here: http://docs.openstack.org/mitaka/networking-guide/ops-resource-tags.html We should review in-tree developer documentation to see whether there's anything missing. Changed in neutron: importance: Undecided → Wishlist assignee: nobody → Hirofumi Ichihara (ichihara-hirofumi) Hide Hirofumi Ichihara (ichihara-hirofumi) wrote 4 hours ago:#2 Yeah, I'll update devref in Neutron tree. ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1662102 Title: Enhance tag mechanism Status in neutron: New Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/413662 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 b56f008f3a01e5dbbf5b0744a9286a8302c3326a Author: Hirofumi IchiharaDate: Thu Jan 19 13:52:39 2017 +0900 Enhance tag mechanism This patch enhances the tag mechanism for subnet, port, subnetpool, router resources. The tag-ext as new extension is added so that tag supports their resources. APIImpact: Adds tag support to subnet, port, subnetpool, router DocImpact: allow users to set tags on some resources Change-Id: I3ab8c2f47f283bee7219f39f20b07361b8e0c5f1 Closes-Bug: #1661608 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1662102/+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 1662644] Re: Enhance tag mechanism
*** This bug is a duplicate of bug 1662102 *** https://bugs.launchpad.net/bugs/1662102 Yes, this has been passed and merged. I'll have to mark this one as a duplicate for manuals: https://bugs.launchpad.net/openstack-manuals/+bug/1662102 ** This bug has been marked a duplicate of bug 1662102 Enhance tag mechanism -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1662644 Title: Enhance tag mechanism Status in neutron: New Status in openstack-manuals: New Bug description: https://review.openstack.org/429621 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 fbf40fe1baac06ce570b660a0a4118e2030c668d Author: Hirofumi IchiharaDate: Thu Jan 19 13:52:39 2017 +0900 Enhance tag mechanism This patch enhances the tag mechanism for subnet, port, subnetpool, router resources. The tag-ext as new extension is added so that tag supports their resources. APIImpact: Adds tag support to subnet, port, subnetpool, router DocImpact: allow users to set tags on some resources Change-Id: I3ab8c2f47f283bee7219f39f20b07361b8e0c5f1 Closes-Bug: #1661608 (cherry picked from commit b56f008f3a01e5dbbf5b0744a9286a8302c3326a) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1662644/+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 1659874] Re: Install and configure in Installation Guide
Hi Mircea, >From what I can see, this might be a Horizon bug, but the doc correct in disabling routers. I will redirect this bug to the horizon team. And close this for openstack-manuals for now. Thank you. ** Also affects: horizon Importance: Undecided Status: New ** Changed in: openstack-manuals Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1659874 Title: Install and configure in Installation Guide Status in OpenStack Dashboard (Horizon): New Status in openstack-manuals: Invalid Bug description: - [ ] This doc is inaccurate in this way: __ in http://docs.openstack.org/newton/install-guide-rdo/horizon-install.html section if you chose networking option 1, disable support for layer-3 networking services: if 'enable_router': False, I always get this error: /var/log/httpd/error_log:[Fri Jan 27 15:29:32.804086 2017] [:error] [pid 14936] TemplateSyntaxError: u'routers' is not a registered namespace inside 'horizon:admin' if 'enable_router': True, all work fine. --- Release: 0.1 on 2017-01-26 10:44 SHA: b31e549708a48752e24a55f1c9c373dd4fa64b21 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/horizon-install.rst URL: http://docs.openstack.org/newton/install-guide-rdo/horizon-install.html To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1659874/+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 1652944] Re: Broken links
** Changed in: openstack-manuals Status: Confirmed => 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/1652944 Title: Broken links Status in neutron: Confirmed Status in openstack-manuals: Fix Released Bug description: The documentation of neutron (see referer below) contains links to pages that do not exist. This was found by a global check of pages on docs.openstack.org using scrapy. {"url": "http://docs.openstack.org/developer/neutron/devref/l2_agent_extensions;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/quality_of_service.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/scenario_legacy_ovs.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/layer3.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/deploy_scenario4b.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/deploy_scenario1b.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/deploy_scenario3b.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/scenario_legacy_lb.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/adv_config_ipv6.html;, "status": 404, "referer": "http://docs.openstack.org/releasenotes/neutron/liberty.html"}, {"url": "http://docs.openstack.org/developer/neutron/devref/l2_agent_extensions;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/quality_of_service.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/scenario_legacy_lb.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/deploy_scenario4b.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/deploy_scenario1b.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/deploy_scenario3b.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/scenario_legacy_ovs.html;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron/devref/layer3.html"}, {"url": "http://docs.openstack.org/newton/networking-guide/adv_config_ipv6.html;, "status": 404, "referer": "http://docs.openstack.org/releasenotes/neutron/liberty.html"}, {"url": "http://docs.openstack.org/developer/openstack-ansible/install-guide-revised-draft/targethosts-networkconfig.html;, "status": 404, "referer": "http://docs.openstack.org/developer/openstack-ansible-os_neutron/newton/app-openvswitch.html"}, {"url": "http://docs.openstack.org/developer/neutron-dynamic-routing/others/testing.rst;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"}, {"url": "http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/route-advertisement.rst;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"}, {"url": "http://docs.openstack.org/developer/neutron-dynamic-routing/design/drivers.rst;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"}, {"url": "http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/dynamic-routing-agent.rst;, "status": 404, "referer": "http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"}, To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1652944/+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 1593436] Re: Fix designate dns driver for SSL based endpoints
This was a dev ref addition. CLosing. ** Changed in: openstack-manuals Status: Confirmed => 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/1593436 Title: Fix designate dns driver for SSL based endpoints Status in neutron: Invalid Status in openstack-manuals: Invalid Bug description: https://review.openstack.org/326958 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 9cd95366a035b29001ce75515d291cf72d07d0c3 Author: imran malikDate: Wed Jun 8 02:45:32 2016 -0700 Fix designate dns driver for SSL based endpoints Allow setting options in designate section to specify if want to skip SSL cert check. This makes it possible to work with HTTPS based endpoints, the default behavior of keystoneclient is to always set verify=True however in current code, one cannot either provide a valid CA cert or skip the verification. DocImpact: Introduce two additional options for `[designate]` section in neutron.conf CONF.designate.insecure to allow insecure connections over SSL. CONF.designate.ca_cert for a valid cert when connecting over SSL Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e Closes-Bug: #1588067 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1593436/+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 1551368] Re: L7 capability extension implementation for lbaas v2
** Changed in: openstack-manuals Status: Confirmed => 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/1551368 Title: L7 capability extension implementation for lbaas v2 Status in neutron: Confirmed Status in openstack-api-site: Invalid Status in openstack-manuals: Invalid Bug description: https://review.openstack.org/148232 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit 254190b3051453f823dbdf1826f1a6b984c57164 Author: Evgeny FedorukDate: Mon Jan 19 03:47:39 2015 -0800 L7 capability extension implementation for lbaas v2 Including extension modifications Including db model modifications Including alembic migration Including new driver managers for l7 rules and policies Inclufing logging_noop driver implementation Including unit testing Including Octavia driver updates DocImpact APIImpact Change-Id: I8f9535ebf28155adf43ebe046d2dbdfa86c4d81b Implements: blueprint lbaas-l7-rules Co-Authored-By: Evgeny Fedoruk Co-Authored-By: Stephen Balukoff To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1551368/+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 1506149] Re: Bodies that are not dicts or lists return 400
Thanks Sana :) ** Tags removed: glance ** Tags added: api-doc ** Changed in: openstack-manuals Status: Confirmed => 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/1506149 Title: Bodies that are not dicts or lists return 400 Status in Glance: Confirmed Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/204138 commit d8ca5c20c51a205624b3e815726e5c103a30b632 Author: Niall BuntingDate: Tue Jul 21 15:22:06 2015 + Bodies that are not dicts or lists return 400 Type errors that are encountered due to unexpected types being passed in now get a 400 'Body format is invalid'. This hardens the glance api from other types. ApiImpact DocImpact Closes-Bug: 1476695 Closes-Bug: 1476253 Change-Id: Ieee0662f67c800b2b3c07c6a8b7877939cf9e1fe To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1506149/+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 1485921] Re: Reservations support
** Changed in: openstack-manuals Status: Confirmed => Invalid ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1485921 Title: Reservations support Status in neutron: New Status in openstack-api-site: Invalid Status in openstack-manuals: Invalid Bug description: https://review.openstack.org/163659 commit 574b25b857419eed74237f61749cb76c4e612fb4 Author: Salvatore OrlandoDate: Wed Mar 11 17:28:43 2015 -0700 Reservations support Add the concept of resource reservation in neutron. Usage tracking logic is also updated to support reservations. Reservations are not however available with the now deprecated configuration-based quota driver. The base API controller will now use reservations to perform quota checks rather than counting resource usage and then invoking the limit_check routine. The limit_check routine however has not been removed and depreacated as a part of this patch. In order to ensure all quota drivers expose a consistent interface, a make_reservation method has been added to the configuration based driver as well. This method simply performs "old-style" limit checks by counting resource usage and then invoking limit_check. DocImpact Implements blueprint better-quotas. Change-Id: Ifea07f461def564884af5b291c8a56655a4d818b To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1485921/+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 1522732] Re: Add availability_zone support for router
Liberty is EOL. Closing. ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1522732 Title: Add availability_zone support for router Status in neutron: Fix Released Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/224418 \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 ef2a5543cc7e15769031f81c921d4babb7e14d04 Author: Hirofumi IchiharaDate: Thu Dec 3 14:12:19 2015 +0900 Add availability_zone support for router This patch adds the availability_zone support for router. APIImpact DocImpact: Make router scheduler availability zone aware. If multiple availability zones are used, set router_scheduler_driver = neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler. This scheduler selects agent depends on LeastRoutersScheduler logic within an availability zone so that considers the weight of agent. Change-Id: Id26d9494b9a5b459767e93a850f47a3b014b11bb Co-Authored-By: IWAMOTO Toshihiro Partially-implements: blueprint add-availability-zone To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1522732/+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 1596927] Re: Glance installation does not appear to detect admin role
Hi everyone, Launchpad is for bug reports and fixes. I recommend you go to ask.openstack.org or perhaps address your question in #openstack on Freenode. Once the issue "It seems that glance is not properly detecting the admin-ness of the admin account, i.e. resolving that admin is in the role admin. If I remove the "role:admin" from publicize_image in /etc/glance/policy.json, the above command works." has been fixed in Glance, we can reopen this and address this in the documentation. Thanks, Alex ** Changed in: openstack-manuals Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1596927 Title: Glance installation does not appear to detect admin role Status in Glance: New Status in openstack-manuals: Invalid Bug description: Following the installation guide on Ubuntu 16.04 and using the provided Mitaka packages on new clean VM installation. Once I attempt to upload an image with the --public flag glance reports 403 Forbidden when using the admin account. (debug output at the end of the bug). Again this is using the ADMIN account who is in the ADMIN role of both the admin and service projects. I'm guessing this is a documentation issue and somewhere along the instructions something's not happenig in the right order. It seems that glance is not properly detecting the admin-ness of the admin account, i.e. resolving that admin is in the role admin. If I remove the "role:admin" from publicize_image in /etc/glance/policy.json, the above command works. The username and password for the glance account in /etc/glance /glance-api.conf and glance-registry.conf are correct. It seems that only those operations that require the admin role are broken. The admin user environment is set as: export OS_PROJECT_DOMAIN_NAME=default export OS_USER_DOMAIN_NAME=default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=admin export OS_AUTH_URL=http://controller:35357/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 The documented roles/projects/users are defined: root@controller:~# openstack user list +--++ | ID | Name | +--++ | 2c2f877dad19415aa2f3c410cc23f7f5 | glance | | 4200ae4f41a24e1195f1fa1f2a6bc7c8 | admin | | df223dbfc8534f089677da8002f084a2 | demo | +--++ root@controller:~# openstack role list +--+---+ | ID | Name | +--+---+ | 5958a2db1dec48a3ae8e01a2b5704080 | admin | | d75766b685a943cca51c7869fe39ee09 | user | +--+---+ root@controller:~# openstack project list +--+-+ | ID | Name| +--+-+ | 0e53ec33b2dd45adcd0a4d432512 | admin | | 24178e2444634949a96877a906ddc6f5 | demo| | 62ce2aaa1a3b4c7c855d11af43eb26a9 | service | +--+-+ root@controller:~# openstack role assignment list --names +---++---+-++---+ | Role | User | Group | Project | Domain | Inherited | +---++---+-++---+ | admin | glance@default | | service@default || False | | admin | admin@default | | admin@default || False | | admin | admin@default | | service@default || False | | user | demo@default | | demo@default|| False | +---++---+-++---+ Debug output: root@controller:~# openstack --debug image create "cirros" --file cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --public START with options: ['--debug', 'image', 'create', 'cirros', '--file', 'cirros-0.3.4-x86_64-disk.img', '--disk-format', 'qcow2', '--container-format', 'bare', '--public'] options: Namespace(access_token_endpoint='', auth_type='', auth_url='http://controller:35357/v3', cacert='', client_id='', client_secret='***', cloud='', debug=True, default_domain='default', deferred_help=False, domain_id='', domain_name='', endpoint='', identity_provider='', identity_provider_url='', insecure=None, interface='', log_file=None, os_compute_api_version='', os_identity_api_version='3', os_image_api_version='2', os_network_api_version='', os_object_api_version='', os_project_id=None, os_project_name=None, os_volume_api_version='', password='***', profile=None, project_domain_id='', project_domain_name='default', project_id='',
[Yahoo-eng-team] [Bug 1439443] Re: Fix web-server memory overrun when downloading objects from Swift
If this should be added to the dev docs, throwing back over the fence to horizon :) Thanks team. ** Also affects: horizon Importance: Undecided Status: New ** Changed in: openstack-manuals Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1439443 Title: Fix web-server memory overrun when downloading objects from Swift Status in OpenStack Dashboard (Horizon): New Status in openstack-manuals: Invalid Bug description: https://review.openstack.org/161204 commit 46405d456d9b056e648a4e60235b4c1b251f1236 Author: Timur SufievDate: Wed Mar 4 16:15:04 2015 +0300 Fix web-server memory overrun when downloading objects from Swift To prevent memory overrun when downloading large objects from Swift * `resp_chunk_size` keyword should be passed to swiftclient * `obj.data` iterator returned from swiftclient is passed to HttpResponse (or StreamingHttpResponse for Django>=1.5) as usual since both response classes work with iterators/files/byte strings (yet StreamingHttpResponse does it better). The commit introduces new setting SWIFT_FILE_TRANSFER_CHUNK_SIZE that defines the size of chunk in bytes for Swift objects downloading. DocImpact Change-Id: I18e5809b86bfa24948dc642da2a55dffaa1a4ce1 Closes-Bug: #1427819 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1439443/+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 1557032] Re: Add "allow_migrate_to_same_host" in deprecated options for nova.conf
Marking as Won't Fix. This needs to be updated in the nova repo, and not the docs repo. So that the files can be updated with the auto-config tool. ** Also affects: nova Importance: Undecided Status: New ** Changed in: openstack-manuals Status: In Progress => Won't Fix -- 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/1557032 Title: Add "allow_migrate_to_same_host" in deprecated options for nova.conf Status in OpenStack Compute (nova): New Status in openstack-manuals: Won't Fix Bug description: default configuration option "allow_migrate_to_same_host" from nova.conf is no longer used. Add this to deprecated options for OpenStack compute. Detailed information can be found at: https://bugs.launchpad.net/nova/+bug/1364851 doc source: openstack-manuals/doc/config-reference/source/tables/conf- changes/nova.rst To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1557032/+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 1567009] Re: Remove flavor seeding from the base migration
** Changed in: openstack-manuals Status: In Progress => Won't Fix ** Changed in: openstack-manuals Status: Won't Fix => Confirmed ** Changed in: openstack-manuals Importance: Undecided => Medium -- 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/1567009 Title: Remove flavor seeding from the base migration Status in OpenStack Compute (nova): Invalid Status in openstack-manuals: Confirmed Bug description: https://review.openstack.org/300127 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/nova" 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 1a1a41bdbe0dc16ca594236925e77ce99f432b9d Author: Dan SmithDate: Thu Mar 31 10:57:14 2016 -0700 Remove flavor seeding from the base migration In a time long ago and a land far far away, someone thought it was a good idea to populate the database with default flavors. That was probably reasonable at the time, but it no longer makes sense and in fact causes us some pain now. This patch removes those default flavors from the database. That means that new deploys will not have them, but doesn't actually rewrite history in any way. This will require changes to our docs, which largely assume the presence of these default flavors from time zero. DocImpact Depends-On: Ic275887e97221d9ce5ce6f12cdcfb5ac94e300b0 Change-Id: I80b63ce1ebca01be61ac0f43d26a2992ecf16678 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1567009/+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 1502773] Re: "Delete Instance" looks better over "Terminate Instance" for consistency
** 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 OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1502773 Title: "Delete Instance" looks better over "Terminate Instance" for consistency Status in OpenStack Dashboard (Horizon): Fix Released Status in openstack-manuals: Fix Released Bug description: "Delete Instance" looks better than "Terminate Instance" for consistency. We use "Terminate Instance" for the action label of deleting a server. I think "Delete Instance" is more consistent from the point of both consistency across OpenStack Dashboard and consistency with nova/openstack CLI. In addition, I think "Delete" is easier for users to associate this operation will delete the instance data completely. "Terminate" is a strong word and native English speaker can image this operation crashes the instance and we can never use it again, but it is not easy that non-native speakers can understand such kind of nuance of the word. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1502773/+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 1557165] Re: Add docs for additional bootstrap endpoint parameters
This should all be up-to-date and relevant. Requires no further documentation. ** Changed in: openstack-manuals Status: Confirmed => Won't Fix -- 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/1557165 Title: Add docs for additional bootstrap endpoint parameters Status in OpenStack Identity (keystone): Invalid Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/290226 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/keystone" 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 258d09a5ac0ee8ed98e8cf6c06319ab7760cf00f Author: Jamie LennoxDate: Wed Mar 9 12:53:45 2016 +1100 Add docs for additional bootstrap endpoint parameters The patch to add the endpoint parameters to the bootstrap command didn't update the documentation to show how to use these commands. Add this information now. Original Patch: Ie78c61ecf1e5f787dd2528b887c1642fd8d457ff Related-Bug: #1550057 DocImpact Change-Id: I5a1cb38b05ebcb8c44c9cf90a490c849f44dbc32 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1557165/+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 1623488] Re: Documentation needed to clarify how to configure auth_endpoint for image signing
The documentation for Barbican resides within their own repo. This does not currently affect the OpenStack manuals project. I recommend the documentation is updated here: http://docs.openstack.org /project-install-guide/key-manager/draft/ ** Changed in: openstack-manuals Status: Confirmed => Opinion ** Also affects: barbican 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/1623488 Title: Documentation needed to clarify how to configure auth_endpoint for image signing Status in Barbican: New Status in OpenStack Compute (nova): Confirmed Status in openstack-manuals: Opinion Bug description: Description === By default Barbican uses http://localhost:5000/v3 for the auth_endpoint (where keystone is). Users should know that this can be changed in nova.conf. This will solve the issue of Barbican being unable to connect to Keystone. Steps to reproduce == If keystone is not on localhost then Barbican will not being able to connect to Keystone. Also, using this documentation to create a signed image: https://github.com/openstack/glance/blob/master/doc/source/signature.rst Then booting the image using 'nova boot'. Note: verify_glance_signatures must be set to true in nova.conf Expected result === Barbican should connect to Keystone to authorize credentials when booting a signed image. Actual result = Barbican cannot connect to Keystone and booting a signed image fails. Environment === This is using the mitaka branch. This also happens in Glance: https://bugs.launchpad.net/glance/+bug/1620539 To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1623488/+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 1639080] Re: Image uploads fail in Horizon if upload mode is set to direct if endpoint set to internal.
Add a note/warning in the horizon role docs. ** Also 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/1639080 Title: Image uploads fail in Horizon if upload mode is set to direct if endpoint set to internal. Status in OpenStack Dashboard (Horizon): New Status in openstack-ansible: New Bug description: With HORIZON_IMAGES_UPLOAD_MODE set to direct Horizon provides the endpoint for Glance based on OPENSTACK_ENDPOINT_TYPE. If OPENSTACK_ENDPOINT_TYPE is set to internalURL any browser outside the internal network is unable to upload images. Setting HORIZON_IMAGES_UPLOAD_MODE to legacy works regardless of what OPENSTACK_ENDPOINT_TYPE is set to, direct should only be used if OPENSTACK_ENDPOINT_TYPE is set to publicURL. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1639080/+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 1627177] Re: Liberty to Mitaka nova list fails when force create a VM on a bad compute node that is not reachable
** Also affects: nova Importance: Undecided Status: New ** Changed in: openstack-ansible Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1627177 Title: Liberty to Mitaka nova list fails when force create a VM on a bad compute node that is not reachable Status in OpenStack Compute (nova): New Status in openstack-ansible: Invalid Bug description: Liberty to Mitaka Upgrade Nova list fails when a user forces a compute creation on one of the nova computes that is in a bad state. nova list limiting to the other hypervisors works though and all other api commands work, except for the nova list. This is happening when u create a vm on a bad compute else it works fine. Log 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack [req-16a27bf2-bebe-4f13-a408-4b5b09129d6c 111ea8c6602e44bc8d7b9a125c86f12a 48d9424cadf145e59c98d5ca53c54f11 - - -] Caught error: 'str' object has no attribute 'metadata' 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack Traceback (most recent call last): 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/nova/api/openstack/__init__.py", line 139, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack return req.get_response(self.application) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/request.py", line 1317, in send 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack application, catch_exc_info=False) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/request.py", line 1281, in call_application 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack app_iter = application(self.environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 144, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack return resp(environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 130, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 195, in call_func 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack return self.func(req, *args, **kwargs) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/keystonemiddleware/auth_token/__init__.py", line 467, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack response = req.get_response(self._app) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/request.py", line 1317, in send 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack application, catch_exc_info=False) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/request.py", line 1281, in call_application 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack app_iter = application(self.environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 144, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack return resp(environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 144, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack return resp(environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/routes/middleware.py", line 136, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack response = self.app(environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 144, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack return resp(environ, start_response) 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack File "/openstack/venvs/nova-13.3.3/lib/python2.7/site-packages/webob/dec.py", line 130, in __call__ 2016-09-23 12:51:24.479 2241 ERROR nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2016-09-23 12:51:24.479 2241 ERROR
[Yahoo-eng-team] [Bug 1593846] Re: Fix designate dns driver for SSL based endpoints
The doc impact for this bug appears to be relevant for neutron documentation, and not for openstack-manuals. Closing as opinion in case anyone with more neutron experience disagrees :) ** Changed in: openstack-manuals Status: New => 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/1593846 Title: Fix designate dns driver for SSL based endpoints Status in neutron: Fix Committed Status in openstack-manuals: Opinion Status in neutron package in Ubuntu: New Bug description: https://review.openstack.org/330817 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 c705e2f9f6c7b4a9db4a80a764268e490ea41f01 Author: imran malikDate: Wed Jun 8 02:45:32 2016 -0700 Fix designate dns driver for SSL based endpoints Allow setting options in designate section to specify if want to skip SSL cert check. This makes it possible to work with HTTPS based endpoints, the default behavior of keystoneclient is to always set verify=True however in current code, one cannot either provide a valid CA cert or skip the verification. DocImpact: Introduce two additional options for `[designate]` section in neutron.conf CONF.designate.insecure to allow insecure connections over SSL. CONF.designate.ca_cert for a valid cert when connecting over SSL Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e Closes-Bug: #1588067 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1593846/+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 1461459] Re: Allow disabling the evacuate cleanup mechanism in compute manager
As suggested, the peril warning was successfully added in the docs but only noted as a partial bug. I think this suffices as a fix. ** 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 OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1461459 Title: Allow disabling the evacuate cleanup mechanism in compute manager Status in OpenStack Compute (nova): Invalid Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/174779 commit 6f1f9dbc211356a3d0e2d46d3a984d7ceee79ca6 Author: Tony BreedsDate: Tue Jan 27 11:17:54 2015 -0800 Allow disabling the evacuate cleanup mechanism in compute manager This mechanism attempts to destroy any locally-running instances on startup if instance.host != self.host. The assumption is that the instance has been evacuated and is safely running elsewhere. This is a dangerous assumption to make, so this patch adds a configuration variable to disable this behavior if it's not desired. Note that disabling it may have implications for the case where instances *were* evacuated, given potential shared resources. To counter that problem, this patch also makes _init_instance() skip initialization of the instance if it appears to be owned by another host, logging a prominent warning in that case. As a result, if you have destroy_after_evacuate=False and you start a nova compute with an incorrect hostname, or run it twice from another host, then the worst that will happen is you get log warnings about the instances on the host being ignored. This should be an indication that something is wrong, but still allow for fixing it without any loss. If the configuration option is disabled and a legitimate evacuation does occur, simply enabling it and then restarting the compute service will cause the cleanup to occur. This is added to the workarounds config group because it is really only relevant while evacuate is fundamentally broken in this way. It needs to be refactored to be more robust, and once that is done, this should be able to go away. Conflicts: nova/compute/manager.py nova/tests/unit/compute/test_compute.py nova/tests/unit/compute/test_compute_mgr.py nova/utils.py NOTE: In nova/utils.py a new section has been introduced but only the option addessed by this backport has been included. DocImpact: New configuration option, and peril warning Partial-Bug: #1419785 (cherry picked from commit 922148ac45c5a70da8969815b4f47e3c758d6974) -- squashed with commit -- Create a 'workarounds' config group. This group is for very specific reasons. If you're: - Working around an issue in a system tool (e.g. libvirt or qemu) where the fix is in flight/discussed in that community. - The tool can be/is fixed in some distributions and rather than patch the code those distributions can trivially set a config option to get the "correct" behavior. This is a good place for your workaround. (cherry picked from commit b1689b58409ab97ef64b8cec2ba3773aacca7ac5) -- Change-Id: Ib9a3c72c096822dd5c65c905117ae14994c73e99 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461459/+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