[Yahoo-eng-team] [Bug 1840927] [NEW] Rewrite doc on L2 population

2019-08-21 Thread Alexandra Settle
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

2019-01-18 Thread Alexandra Settle
** 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

2017-09-18 Thread Alexandra Settle
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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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 Migliaccio 
  Date:   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

2017-09-12 Thread Alexandra Settle
** 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 Szombathelyi 
  Date:   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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
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 Ajo 
  Date:   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

2017-09-12 Thread Alexandra Settle
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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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 Hrachyshka 
  Date:   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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
** 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

2017-09-12 Thread Alexandra Settle
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 Kotlin 
  Date:   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).

2017-08-03 Thread Alexandra Settle
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

2017-05-22 Thread Alexandra Settle
** 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

2017-05-04 Thread Alexandra Settle
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

2017-04-04 Thread Alexandra Settle
** 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 Evrard 
  Date:   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

2017-04-04 Thread Alexandra Settle
** 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 Guyot 
  Date:   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

2017-02-10 Thread Alexandra Settle
** 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

2017-02-08 Thread Alexandra Settle
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 Ichihara 
  Date:   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

2017-02-08 Thread Alexandra Settle
*** 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 Ichihara 
  Date:   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

2017-01-30 Thread Alexandra Settle
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

2017-01-26 Thread Alexandra Settle
** 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

2017-01-26 Thread Alexandra Settle
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 malik 
  Date:   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

2017-01-25 Thread Alexandra Settle
** 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 Fedoruk 
  Date:   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

2017-01-25 Thread Alexandra Settle
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 Bunting 
  Date:   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

2017-01-24 Thread Alexandra Settle
** 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 Orlando 
  Date:   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

2017-01-24 Thread Alexandra Settle
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 Ichihara 
  Date:   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

2017-01-24 Thread Alexandra Settle
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

2017-01-24 Thread Alexandra Settle
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 Sufiev 
  Date:   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

2017-01-18 Thread Alexandra Settle
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

2017-01-18 Thread Alexandra Settle
** 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 Smith 
  Date:   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

2017-01-18 Thread Alexandra Settle
** 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

2017-01-18 Thread Alexandra Settle
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 Lennox 
  Date:   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

2017-01-17 Thread Alexandra Settle
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.

2016-11-15 Thread Alexandra Settle
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

2016-10-04 Thread Alexandra Settle
** 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

2016-07-05 Thread Alexandra Settle
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 malik 
  Date:   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

2016-06-07 Thread Alexandra Settle
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 Breeds 
  Date:   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