Re: [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?

[Morgenstern, Chad]

I have been studying how to perform failover operations with Cinder --failover. 
 Nova is not aware of the failover event. Being able to refresh the connection 
state especially for Nova would come in very handy, especially in admin level 
dr scenarios.

I'm attaching the blog I wrote on the subject:
http://netapp.io/2017/08/09/cinder-cheesecake-things-to-consider/


-Original Message-
From: Arne Wiebalck [mailto:arne.wieba...@cern.ch] 
Sent: Wednesday, September 13, 2017 11:53 AM
To: Matt Riedemann 
Cc: openstack-operators@lists.openstack.org; OpenStack Development Mailing List 

Subject: Re: [Openstack-operators] [nova][cinder] Is there interest in an 
admin-api to refresh volume connection info?


> On 13 Sep 2017, at 16:52, Matt Riedemann  wrote:
> 
> On 9/13/2017 3:24 AM, Arne Wiebalck wrote:
>> I’m reviving this thread to check if the suggestion to address 
>> potentially stale connection data by an admin command (or a scheduled 
>> task) made it to the planning for one of the upcoming releases?
> 
> It hasn't, but we're at the PTG this week so I can throw it on the list of 
> topics.


That’d be great, thanks!

--
Arne Wiebalck
CERN IT

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

[Morgenstern, Chad]

I tried to convert all docs to rst using pandoc as the following example shows
pandoc -f docbook -t rst -s section_cinder-deployment-choices.xml -o 
section_cinder-deployment-choices.rst

There were no errors thrown, however we are missing things such as section 
headers, and the internal links did not convert either.

Please advise how to address this issue?

P.S.
By way of example: 


For example, in the rst doc these are this is what we have
debian@debian-1:~/openstack-repo/openstack-deploy-ops-guide/cinder$ egrep -B 1 
"^\*\*|^\-\-|^==" section_cinder-deployment-choices.rst | egrep -v '^-'  | grep 
-v "^$"
Theory of Operation & Deployment Choices

**Cinder Backends and Storage Virtual Machines.**
**Cinder volumes and FlexVol volumes.**
**Cinder volume representation within a FlexVol volume.**
**Cinder Scheduling and resource pool selection.**
**Cinder snapshots versus NetApp Snapshots.**
**E-Series snapshots.**
**CDOT and 7-mode consistency groups.**
**E-Series consistency groups.**
**SANtricity Web Services Proxy.**
**FAS.**
**E-Series.**
**iSCSI.**
**NFS.**
**Volume Groups.**
**Dynamic Disk Pools (DDP).**
**Options.**
**Setup.**
**Filer Side Setup.**
**OpenStack Setup.**
**Data ONTAP Thin Provisioning.**
**E-Series Thin Provisioning.**
**Establishing an iSCSI Session.**
**iSCSI Session Scope.**
**Configuration Options.**

Where as in the original xml file:
debian@debian-1:~/openstack-repo/openstack-deploy-ops-guide/cinder$ grep -i 
title section_cinder-deployment-choices.xml
Theory of Operation  Deployment Choices
Construct Mappings between Cinder and Data ONTAP
Cinder Backends and Storage Virtual Machines
Cinder volumes and FlexVol volumes
Cinder volume representation within a FlexVol volume
Cinder Scheduling and resource pool selection
Cinder snapshots versus NetApp Snapshots
E-Series snapshots
CDOT and 7-mode consistency groups
E-Series consistency groups
SANtricity Web 
Services Proxy
SANtricity Web 
Services Proxy
Mitaka Support
Recommendation
Deployment Choice: FAS vs E-Series
FAS
E-Series
Deployment Choice: Clustered Data ONTAP vs Data ONTAP operating 
in 7-Mode
Recommendation
Deployment Choice: NFS versus iSCSI
iSCSI
NFS
Recommendation
Recommendation
Deployment Choice: Volume Groups vs Dynamic Disk Pools 
(E-Series)
Volume Groups
Dynamic Disk Pools (DDP)
Recommendation
Deployment Choice: NFS Security
Options
  Setup
  Filer Side Setup
  OpenStack Setup
Fibre Channel Switch Fabric With Cinder
Using Cinder Volume Types to Create a Storage Service 
Catalog
Over-Subscription and Thin-Provisioning
  Data ONTAP Thin Provisioning
  E-Series Thin Provisioning
Unidirectional CHAP Authentication
  Establishing an iSCSI Session
  iSCSI Session Scope
  Configuration Options

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Thursday, August 10, 2017 8:37 AM
To: openstack-operators 
Subject: Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide 
removal

Excerpts from Yuki Kasuya's message of 2017-08-10 17:09:48 +0900:

> 
> I tried to convert all docs under ops-guide dir using pandoc. Like 
> below, toctree,term and some directives doesn't work after converting.
> But, at glance, almost fine after converting.
> If you don't mind, I'll able to create wiki pages of ops-guide.
> 
> xxx@devstack02:~/work/openstack-manuals/doc/ops-guide/source$ pandoc 
> index.rst -t mediawiki -o index .wiki
> pandoc: ignoring unknown directive: toctree "source" (line 58, column 
> 1)
> pandoc: ignoring unknown role :term: in "source" (line 20, column 13)
> pandoc: ignoring unknown role :term: in "source" (line 19, column 59)

It should be safe to ignore the toctree directives. If you want to keep the 
same structure between the wiki pages and the original source document, you 
might want to replace those with lists of links.

The term role automatically links to the glossary. As long as the text 
highlighted by the role is present in the output, it is fine to ignore that 
warning, too.

Doug

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova]

[Morgenstern, Chad]

Hi,

I am trying to programmatically rebuild a nova instance that has a persistent 
volume for its root device.
I am specifically trying to rebuild an instance that has multiple network 
interfaces and a floating ip.
I have observed that the order in which the network interface are attached  
matters, floating ip attach to eth0 based.
How do I figure out which of the interfaces currently attached is associated 
with eth0?
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators